Diseñar pantallas sin reglas de negocio es diseñar a ciegas
Actualizado: 6 sept
Una pantalla puede verse perfectamente diseñada y, aun así, representar un producto que no sabe qué debe hacer. Cuando el diseño comienza antes de definir las reglas del negocio, la interfaz deja de resolver decisiones y empieza a esconder preguntas pendientes.
En muchos proyectos digitales ocurre algo extraño: el equipo todavía no sabe con precisión quién puede hacer qué, bajo qué condiciones, qué sucede cuando algo falla o qué excepciones existen, pero ya está diseñando pantallas. Se discute el menú, se prueba una navegación, se decide dónde colocar un botón e incluso puede existir un prototipo visualmente convincente. El problema es que debajo de esas pantallas todavía no existe un sistema suficientemente definido.
Una interfaz no es solamente lo que el usuario ve
Cada acción dentro de una aplicación representa una decisión. Si un usuario presiona Cancelar reserva, alguien tuvo que determinar hasta cuándo puede hacerlo, qué sucede con el pago, qué ocurre si la reservación ya comenzó, quién puede autorizar una excepción y qué mensaje aparecerá cuando la cancelación no sea posible. Eso es una regla de negocio. Las reglas determinan condiciones, permisos, restricciones, cálculos, prioridades, estados y excepciones. IBM las describe como la lógica que permite establecer qué actividad debe ocurrir ante determinadas circunstancias, mientras que estándares como Decision Model and Notation (DMN), de Object Management Group, existen precisamente para representar este tipo de decisiones de manera estructurada.
“La pantalla es la parte visible del producto; las reglas de negocio son las que deciden si esa pantalla tiene sentido.”
Puedes escuchar este artículo aquí:
Diseñar únicamente la capa visible significa trabajar sobre una fracción del problema. Un flujo suele parecer sencillo mientras todos imaginan el escenario ideal: el usuario se registra, selecciona un servicio, paga y recibe una confirmación. Pero los productos reales viven en las excepciones. ¿Qué ocurre si ya tiene una cuenta? ¿Si el servicio dejó de estar disponible mientras pagaba? ¿Si existen diferentes precios según el usuario? ¿Si solamente determinados perfiles pueden aprobar una solicitud? ¿Si el pago se procesa pero la operación posterior falla?
Cada una de esas respuestas puede modificar el flujo, la arquitectura de información, los mensajes, los permisos e incluso la cantidad de interfaces necesarias. También puede cambiar el comportamiento de una misma pantalla dependiendo del estado del proceso: pendiente, confirmado, aprobado, rechazado, vencido o cancelado. Por eso descubrir estas reglas después de diseñar no es un detalle menor: significa regresar sobre decisiones que parecían terminadas.
Figma no debería ser el lugar donde se descubre cómo funciona el negocio
El problema no es utilizar Figma demasiado pronto. El problema es utilizarlo para responder preguntas que deberían haberse resuelto antes. Antes de diseñar una operación crítica deberían estar documentados, al menos, los actores involucrados, sus permisos, las condiciones necesarias para ejecutar cada acción, los estados posibles del proceso y sus principales excepciones.
Incluso algo aparentemente trivial como un formulario depende de esas decisiones. GOV.UK recomienda definir antes de diseñarlo qué información necesita realmente el servicio, por qué la necesita, qué hará con ella, quién debe proporcionarla y cómo se comprobará su validez. También plantea utilizar ramificaciones para mostrar únicamente las preguntas relevantes para cada usuario. No es decoración de formularios. Es diseño del funcionamiento.
Una pantalla bonita puede ocultar una decisión mal definida
Imaginemos una aplicación para administrar solicitudes de crédito. Diseñar una pantalla con los botones Aprobar y Rechazar es sencillo. Diseñar el producto no. Hay que establecer quién puede aprobar, qué información necesita consultar, qué montos requieren autorización adicional, cuándo una solicitud debe escalarse, qué ocurre con los casos incompletos, qué motivos de rechazo existen y qué acciones puede realizar posteriormente el solicitante. Sin esas respuestas, los botones son solamente rectángulos de colores.
“Cuando las reglas no están documentadas, el diseñador termina inventando el negocio mientras diseña la interfaz.”
Puedes ver este artículo aquí:
Ese es uno de los riesgos más frecuentes cuando un proyecto entra demasiado pronto a la etapa visual. El diseñador empieza a tomar decisiones que parecen de interfaz, pero que en realidad pertenecen al negocio, a la operación o al producto. El problema no es solamente de UX: esas decisiones improvisadas terminan trasladándose a desarrollo, donde se convierten en ambigüedad, retrabajo, cambios de alcance y funcionalidades que deben redefinirse cuando el proyecto ya es más costoso de modificar.
El criterio debe venir antes que la interfaz
Diseñar productos digitales requiere transformar operaciones, decisiones y necesidades en comportamientos comprensibles para las personas. Por eso el trabajo previo no debería limitarse a preguntar qué pantallas necesita una empresa. Hay que entender qué decisiones toma, quién puede tomarlas, qué condiciones las modifican, qué estados atraviesa cada proceso, dónde existen excepciones y qué información necesita el sistema para responder correctamente.
Cuando esas reglas están claras, el diseño se vuelve mucho más preciso. Los flujos aparecen con mayor lógica, los estados dejan de improvisarse, las excepciones pueden anticiparse y desarrollo recibe especificaciones mucho menos ambiguas. En Sr. Zorro creemos que una interfaz debería ser consecuencia de un producto entendido, no el instrumento utilizado para intentar entenderlo. Documentar las reglas antes de diseñar no hace más lento el proyecto: reduce la cantidad de decisiones costosas que habrá que corregir después.
¿Tus pantallas representan decisiones ya definidas o están ocultando decisiones que nadie ha tomado todavía?
¿Tu idea necesita más claridad antes de convertirse en código? En Sr. Zorro App Design Studio te ayudamos a definir, validar y diseñar productos digitales listos para desarrollo. Conoce más en www.srzorro.com.
Escrito por:Editorial
Fuentes
IBM — ¿Qué son las Business Rules? Consultar fuente en IBM
IBM — Sistemas de gestión de Business Rules Consultar fuente en IBM
IBM — Gestión de decisiones Consultar fuente en IBM
Object Management Group — Decision Model and Notation (DMN) Consultar estándar DMN
GOV.UK Service Manual — Structuring forms Consultar fuente en GOV.UK
GOV.UK Design System — Check a service is suitable Consultar fuente en GOV.UK
Comentarios