Diseño de la matriz de aprobación antes de la UI: mapea las reglas antes de las pantallas

Por qué fallan las pantallas sin una matriz clara

Una pantalla limpia puede ocultar un proceso desordenado. Si la lógica de aprobación no se define primero, la gente puede ver botones de Aprobar y Rechazar pero aún así no saber quién debe actuar, cuándo debe hacerlo o qué sucede después.

Esa confusión aparece rápido en el trabajo real. Alguien envía una solicitud, llega a la app y la primera pregunta es: "¿Va esto al gerente, a finanzas o a ambos?" La pantalla parece terminada, pero falta el camino de decisión.

Esto sucede porque las pantallas hacen que las reglas parezcan más simples de lo que son. Un formulario puede mostrar estado, comentarios y botones de acción, pero no puede adivinar la matriz de aprobación real que hay detrás del proceso. Si la empresa tiene límites por monto, reglas por departamento o delegados temporales, la interfaz empieza a fallar en cuanto aparecen esos casos.

A menudo basta con una excepción para que el trabajo salga de la app. Tal vez las aprobaciones suelen ir al jefe de departamento, salvo cuando la solicitud es urgente, supera cierta cantidad o el aprobador está de permiso. Si ese caso nunca se mapeó, la gente recurre al correo, al chat o a hojas de cálculo.

Entonces surge un problema mayor: cada equipo empieza a aplicar su propia versión de las reglas. Operaciones envía la solicitud de una forma, finanzas de otra y soporte maneja excepciones distinto a RR. HH. La app se convierte en una pantalla compartida para decisiones inconsistentes en vez de en un proceso compartido.

Las señales de advertencia suelen ser fáciles de detectar:

• los usuarios preguntan quién es el responsable del siguiente paso
• solicitudes similares tienen resultados distintos entre equipos
• las excepciones se manejan por chat o correo
• los cambios de política fuerzan cambios en la pantalla en vez de cambios en las reglas

Las actualizaciones de política exponen esta debilidad rápido. Cuando la lógica vive dentro de la pantalla en lugar de en reglas de flujo claras, cada cambio de umbral o de rol se convierte en rehacer la UI. Eso ralentiza a los equipos, genera errores y hace que los usuarios pierdan confianza.

La pantalla debe reflejar el camino de decisión, no definirlo. Cuando la matriz está clara primero, la interfaz es más simple, estable y fácil de usar.

Qué mapear antes de cualquier wireframe

Empieza por la lógica de decisión, no por la pantalla. Una matriz de aprobación sólida comienza como una tabla simple que muestra quién puede aprobar qué, bajo qué condiciones y qué pasa cuando alguien no está disponible. Si esa lógica es borrosa, incluso una interfaz pulida confundirá a la gente.

Para cada tipo de solicitud, mapea los niveles de aprobación en orden. Anota el rol que posee cada paso y lo que permite ese paso: aprobar, rechazar, revisar o devolver para corrección. Los roles funcionan mejor que los nombres personales porque las personas se mueven, los equipos cambian y el proceso debe sostenerse.

Luego define las reglas que cambian la ruta. El monto es el detonante obvio, pero rara vez es el único. Las reglas de flujo de aprobación suelen depender de región, departamento, tipo de proveedor, categoría de solicitud o nivel de riesgo. El mismo monto puede ser rutinario en un equipo y sensible en otro.

Las ausencias también necesitan reglas. Si el aprobador principal está fuera, ¿quién toma el relevo de inmediato? Si el respaldo es temporal, ¿qué fechas aplican? Sin eso, las solicitudes se quedan estancadas porque nadie sabe quién las gestiona esa semana.

Los límites de tiempo importan igual. Decide qué sucede cuando una solicitud no recibe respuesta. Puedes enviar un recordatorio después de un día, escalar después de dos y notificar a operaciones tras tres. Esas decisiones afectan etiquetas de estado, notificaciones y vistas de cola, por lo que deben resolverse antes de empezar el diseño de pantallas.

Una matriz práctica suele responder cinco preguntas básicas:

• ¿Qué condición inicia esta regla?
• ¿Qué rol aprueba en esta etapa?
• ¿Quién es el respaldo?
• ¿Cuánto tiempo tiene el aprobador para actuar?
• ¿Qué sucede si se incumple el plazo?

Si mapeas esas respuestas temprano, el resto de la construcción se vuelve mucho más fácil.

Cómo construir la matriz paso a paso

Usa una tabla, una pizarra o una hoja de cálculo. Mantenla lo bastante simple para que un gerente, un líder de equipo y el dueño del proceso la entiendan a primera vista.

Primero, lista cada tipo de solicitud que necesita aprobación. No forces todo en un flujo genérico si el negocio ya trata las solicitudes de forma distinta. Una solicitud de compra, una devolución, la aprobación de un descuento y una petición de acceso suelen necesitar aprobadores, límites y plazos diferentes.

Luego, escribe el primer aprobador y cada punto de decisión después de ese. Para cada tipo de solicitud, anota quién la revisa primero y qué sucede tras una aprobación o un rechazo. Sigue la ruta hasta llegar a un resultado final como aprobado, rechazado, devuelto para corrección o cancelado.

Después, añade los umbrales que cambian la ruta. Aquí es donde muchos equipos se atascan más tarde. Si una solicitud por debajo de $500 va al líder de equipo pero cualquier monto superior va al jefe de departamento, escríbelo ahora. Si las solicitudes urgentes saltan un paso o siguen un camino más rápido, captura eso también.

Luego registra excepciones, plazos y estados finales. Incluye casos como documentos faltantes, solicitudes duplicadas, violaciones de política y aprobaciones vencidas. La regla no está completa hasta que sabes cómo se comporta cuando algo sale mal.

Finalmente, revisa el borrador con las personas que hoy aprueban solicitudes. Pregunta dónde suelen estancarse, dónde se saltan pasos y qué ocurre cuando el aprobador habitual no está disponible. Los hábitos reales suelen revelar reglas que nunca fueron documentadas.

Un ejemplo pequeño lo deja claro. Imagina una solicitud de compra: material de oficina por menos de $200 va al líder de equipo; software entre $200 y $2,000 va al gerente de departamento; y cualquier monto superior también necesita finanzas. Si el formulario no captura el monto y la categoría de entrada, la UI no puede enviar la solicitud por la ruta correcta.

Establece umbrales que la gente pueda seguir

Los umbrales solo funcionan cuando la gente puede leerlos rápido y tomar la misma decisión cada vez. Si una regla dice "compras pequeñas" o "proveedores de alto riesgo", distintas personas lo interpretarán distinto. Usa números fijos, fechas y condiciones nombradas en su lugar.

Una regla más clara suena así: "Hasta $1,000 va al líder de equipo. $1,001 a $5,000 va al gerente de departamento. Más de $5,000 va a finanzas y al director." Nadie tiene que adivinar dónde pertenece la solicitud.

El monto es común, pero no debería ser el único detonante si tu proceso depende de otros factores. Una compra de software de bajo costo con un proveedor nuevo puede necesitar más revisión que una orden mayor de un proveedor aprobado.

La mayoría de los equipos solo necesita un conjunto pequeño de reglas de enrutamiento. Ejemplos comunes incluyen rangos de monto, estado del proveedor, categoría de compra, departamento y urgencia. Lo importante no es la cantidad de reglas, sino que todos las apliquen de la misma forma.

El orden de las reglas también importa. Si la gente no sabe qué condición tiene prioridad, enrutará la misma solicitud de forma distinta. Elige un orden y mantenlo consistente. Puedes comprobar primero el estado del proveedor, luego la categoría y después el monto. O comprobar monto primero y manejar excepciones después. Cualquiera de los dos funciona si todos siguen la misma secuencia.

También ayuda definir quién puede anular un umbral y cuándo. Sin eso, el personal o bien espera demasiado o bien elude el proceso por correo y chat. "El director de finanzas puede aprobar solicitudes por encima del límite durante el cierre del mes" es útil. "La alta dirección puede hacer excepciones" no lo es.

Una prueba simple funciona bien: da el mismo ejemplo de solicitud a tres personas y pregunta adónde debería ir. Si dan tres respuestas distintas, los umbrales siguen siendo demasiado vagos.

Planifica aprobadores de respaldo, sustitutos y escalaciones

Una matriz fuerte no termina en el aprobador principal. El trabajo real sigue avanzando cuando alguien está de permiso, enfermo o simplemente no responde a tiempo. Si no planificas eso desde el inicio, la pantalla puede verse ordenada mientras el proceso se queda paralizado.

Empieza nombrando al aprobador de respaldo para cada paso importante. Debe ser una persona o un rol con el contexto correcto, no solo "el siguiente gerente" por defecto. Si un jefe de finanzas aprueba gastos por encima de cierta cantidad, decide quién toma el relevo cuando esa persona no esté disponible.

Los sustitutos temporales necesitan límites. Un sustituto debe recibir derechos de aprobación solo por un periodo definido, como fechas de vacaciones o licencia planificada. Eso mantiene la responsabilidad clara y evita casos donde alguien conserva el acceso de aprobación mucho después de lo debido.

Una configuración simple debería responder cuatro cosas: quién es el aprobador principal, quién es el respaldo, cuánto tiempo puede actuar el sustituto y cuándo la solicitud se eleva en la cadena.

Las escalaciones deben basarse en detonantes claros, no en conjeturas. Detonantes comunes incluyen tiempo, monto, riesgo o información faltante. Por ejemplo, si una solicitud de compra por encima de $10,000 permanece sin tocar por 24 horas, podría escalar al jefe de departamento.

Mantén la ruta de escalación corta. Si las personas necesitan un diagrama complejo solo para entender quién recibe la solicitud a continuación, la regla probablemente sea demasiado complicada. Uno o dos saltos claros suelen ser suficientes.

Registra cada decisión también. Guarda quién aprobó, quién sustituyó, cuándo ocurrió el traspaso y por qué la solicitud se escaló. Ese historial importa cuando alguien luego pregunta por qué una solicitud se demoró o fue aprobada por un respaldo.

Una regla más importa más de lo que parece: evita bucles. Una solicitud nunca debe rebotar a alguien que ya la aprobó, ni a un sustituto que actúe por esa misma persona. Revisa la matriz en busca de rutas circulares antes de construir cualquier lógica en la app.

Un ejemplo sencillo: aprobación de solicitud de compra

Imagina una pequeña empresa comprando artículos de uso diario. Un empleado envía una solicitud con el artículo, el monto, la razón y la fecha requerida. El enrutamiento se rige por las reglas, no por quién está en línea.

Si la solicitud es por $420, va directo al líder de equipo. Eso mantiene las compras pequeñas en movimiento. Una solicitud de $3,200 salta al gerente de departamento porque el impacto presupuestario es mayor.

Ahora toma una solicitud de $7,800 para equipo nuevo. El gerente de departamento la revisa, pero no es suficiente. Como el monto supera $5,000, finanzas también debe revisarla. Ahí es donde una matriz clara ayuda: los montos mayores añaden control sin generar adivinanzas.

Las ausencias importan aquí también. Si el gerente de departamento está de permiso, la solicitud no debe quedarse en limbo. Un sustituto nombrado la recibe automáticamente y puede actuar por ese periodo definido.

Los límites de tiempo necesitan el mismo nivel de claridad. Si nadie actúa en dos días, la solicitud escala a operaciones. Operaciones puede hacer seguimiento, reasignarla o asegurarse de que no bloquee el trabajo.

En este ejemplo, la matriz responde algunas preguntas simples pero importantes: cuánto se solicita, qué rol aprueba en cada monto, cuándo se suma finanzas, quién cubre ausencias y qué pasa si se incumple un plazo.

Una vez definidas esas respuestas, el diseño de pantallas se vuelve directo. El formulario solo necesita los datos correctos y la página de la solicitud solo debe mostrar el aprobador actual, cualquier sustituto y si el reloj de escalación está corriendo.

Errores comunes que causan retrabajo

La mayoría del retrabajo comienza antes de dibujar una sola pantalla. Los equipos adivinan la ruta de aprobación y luego intentan hacer que la UI encaje con reglas que nunca se acordaron.

Un error común es copiar el organigrama y llamarlo flujo. Eso puede verse ordenado, pero las solicitudes reales suelen moverse por monto, riesgo, ubicación o tipo. Si la matriz lo ignora, las pantallas necesitarán después campos extra, estados adicionales y excepciones incómodas.

Otro problema es olvidar casos especiales. Solicitudes urgentes, compras reguladas o peticiones entre equipos a menudo necesitan una ruta distinta. Si esas excepciones no se mapean temprano, la gente pide soluciones manuales y la interfaz se llena de opciones puntuales que confunden a todos.

Los equipos también generan problemas cuando asignan a dos personas exactamente la misma tarea sin regla de desempate. Si ambos pueden aprobar, ¿quién actúa primero? Si están en desacuerdo, ¿qué decisión vale? Sin esa respuesta, las solicitudes rebotan y los usuarios pierden confianza.

Las reglas de sustitutos son otro punto débil. Un sustituto debe cubrir una ausencia, no convertirse en propietario secundario para siempre. Cuando la cobertura temporal y la propiedad permanente se mezclan, los informes se vuelven confusos y la rendición de cuentas desaparece.

Diseñar formularios antes de que el enrutamiento esté resuelto genera otra ronda de retrabajo. Un formulario puede parecer completo, pero una vez finalizadas las reglas de aprobación, a menudo descubres campos faltantes como banda de monto, departamento, urgencia o marca de política. Entonces el diseño, la validación y las notificaciones deben cambiar.

Una comprobación rápida ayuda a detectar esto temprano:

• ¿Pueden dos aprobadores recibir la misma solicitud al mismo tiempo?
• ¿Hay una diferencia clara entre respaldo temporal y propiedad permanente?
• ¿Los casos urgentes o regulados siguen una ruta distinta?
• ¿Cada decisión de enrutamiento depende de un campo que ya existe?
• ¿El proceso seguiría teniendo sentido si un aprobador dejara la empresa?

Si alguna respuesta no está clara, detente ahí. Arregla la matriz antes de pulir las pantallas.

Chequeos rápidos antes de diseñar las pantallas

Antes de dibujar un formulario o una insignia de estado, prueba la lógica en lenguaje llano. Una buena matriz de aprobación debe explicarse fácil sin abrir un diagrama. Si un gerente, un líder de finanzas o un colega de operaciones no puede describir la ruta en alrededor de un minuto, el proceso aún es demasiado vago para trabajar la UI.

Haz una revisión rápida con ejemplos reales. Pide a una persona que explique la ruta completa desde la solicitud hasta la decisión final. Verifica que cada resultado probable tenga un siguiente aprobador nombrado, no solo el camino feliz. Reescribe umbrales vagos como reglas exactas del tipo "$1,000 o menos" o "más del 10% de descuento". Confirma que las reglas de respaldo y escalación usan límites de tiempo claros como "después de 24 horas" o "después de 2 días hábiles."

Luego prueba la trazabilidad. Más adelante, alguien preguntará por qué una solicitud se retrasó, quién aprobó una excepción o cuándo intervino un sustituto. Tu proceso debe responder ya esas preguntas. Marcas de tiempo, historial de decisiones y cambios de estado claros no son extras. Son parte del conjunto de reglas.

Un escenario simple suele exponer puntos débiles. Imagina una solicitud de $4,800 que llega un viernes por la tarde mientras el aprobador usual está fuera. ¿Quién la recibe luego? ¿Cuánto espera el sistema antes de moverla? ¿Qué pasa si el respaldo tampoco hace nada? Si esas respuestas no están escritas, la UI ocultará la confusión en lugar de resolverla.

Cuando estas comprobaciones pasan, el diseño de pantallas es mucho más fácil. Ya no estás adivinando qué debe mostrar la interfaz. Estás dando forma clara a reglas claras.

Próximos pasos: convierte la matriz en una app funcional

Una vez que las reglas estén claras, construye el proceso antes de pulir las pantallas. Empieza por la lógica, los campos de datos y los estados de aprobación. Si el enrutamiento funciona, la interfaz será mucho más fácil de diseñar. Si el enrutamiento aún cambia, las pantallas atractivas solo ocultarán los problemas.

Una primera versión práctica suele incluir lo básico: tipo de solicitud, monto, departamento, aprobador actual, estado final y un historial claro de cada decisión. Luego añade las reglas que mueven una solicitud hacia adelante, la envían a un aprobador de respaldo o activan una escalación cuando alguien no responde a tiempo.

Mantén las primeras pantallas simples. Un solicitante debe poder enviar, consultar el estado y responder a preguntas de seguimiento. Un aprobador debe poder revisar, aprobar, rechazar o reasignar. Eso es suficiente para probar si el flujo tiene sentido en el uso diario.

Un orden de construcción sensato es sencillo:

• define los campos de datos principales y los valores de estado
• añade reglas de enrutamiento para umbrales, aprobadores de respaldo, sustitutos y escalaciones
• crea pantallas básicas para solicitantes y aprobadores
• asegura que cada canal use la misma fuente de la verdad
• prueba una solicitud real de principio a fin antes de desplegarla a más usuarios

Esa fuente de la verdad compartida importa más de lo que muchos equipos esperan. Si el móvil muestra un estado, el panel web otro y el backend sigue umbrales distintos, la confianza desaparece rápido.

Si estás construyendo esto en AppMaster, una matriz clara facilita mucho la configuración. Puedes modelar los datos, la lógica de negocio y el flujo de aprobación primero, y después llevar el mismo proceso al backend, la web y el móvil sin reescribir las reglas en herramientas separadas.

Usa un caso real para la primera prueba. Ejecuta una solicitud de compra con un umbral, un aprobador sustituto y una escalación por vencimiento. Observa dónde la gente duda, qué datos faltan y qué etiquetas de estado confunden.

Mejora el texto y el diseño después de eso. Cuando el proceso funciona con una solicitud real, las pantallas son más fáciles de diseñar y mucho menos propensas a ser rehechas una semana después.