«Solo necesitamos un formulario para cargar datos en una lista de SharePoint y luego lo visualizamos en Power BI. Algo rápido.»
Como diseñadora UX/UI, he escuchado esta frase muchas veces. La arquitectura técnica sonaba estándar y el requerimiento, a primera vista, parecía inofensivo. La premisa de los stakeholders era lineal: la herramienta es «Low-Code», por lo tanto, el diseño debería ser «Low-Effort», ¿verdad?
Hace poco me enfrenté a este desafío. Lo que llegó a mi devops y en la daily del equipo como una petición de «una pantalla sencilla» se transformó en un ejercicio profundo de estrategia tras hablar con las personas que realmente iban a usar el ecosistema.
La trampa de la arquitectura «obvia»
El flujo técnico estaba claro: PowerApps (Entrada) → SharePoint (Almacenamiento) → Power BI (Reporte). Sobre el papel, la lógica funcionaba. Pero cuando decidí no quedarme con esa visión y entrevistar a tres usuarios clave, la «simplicidad» se desmoronó para dar paso a la realidad.
Esto fue lo que me encontré:
Usuario 1: El Operativo (La entrada de datos)
Era quien alimentaba al monstruo (SharePoint).
- Su realidad: Trabajaba en movimiento, en el campo, a veces con mala conexión y desde un dispositivo móvil.
- Su dolor: «Si tengo que esperar a que cargue una lista gigante de SharePoint o hacer mil clics, prefiero anotarlo en un papel y cargarlo luego».
- Su necesidad real: Velocidad pura. Botones grandes, modo offline y un formulario que solo le pida lo estrictamente necesario.
Usuario 2: El Supervisor (La validación)
El guardián de la calidad de los datos.
- Su realidad: Tenía miedo de «ensuciar» la base de datos con errores. Necesitaba revisar antes de que la data llegara al reporte final.
- Su dolor: «No confío en lo que se carga. Necesito ver el detalle crudo y poder editar o rechazar sin miedo a borrar algo importante».
- Su necesidad real: Control y trazabilidad. Una interfaz tipo «grid» o tabla dentro de la app que le diera la seguridad visual de un Excel, pero con reglas de validación.
Usuario 3: El Gerente (La visión macro)
El consumidor del Power BI. Él nunca iba a abrir la PowerApp.
- Su realidad: Necesitaba tomar decisiones los lunes a las 8:00 AM.
- Su dolor: «No entiendo por qué los números de las solicitudes cargadas no cuadran con lo que me dicen en los pasillos». (El problema no era el reporte, era que los operativos no cargaban datos a tiempo porque la app era difícil de usar).
- Su necesidad real: Confianza en la data. Necesitaba que el input fuera tan sencillo que su dashboard de Power BI estuviera siempre actualizado en tiempo real.
El conflicto: Cuando las necesidades chocan
Aquí estaba el problema: Una sola pantalla «simple» no podía satisfacer a los tres. Diseñar una app genérica hubiera resultado en un Operativo frustrado por la lentitud, un Supervisor inseguro y un Gerente con un Power BI lleno de datos desactualizados.
El desafío estratégico: Más allá del «Canvas»
Para un cliente de la envergadura de Raona Argentina, la escalabilidad y la adopción eran críticas. No se trataba solo de pintar pantallas, sino de entender que en el ecosistema Microsoft, el diseño es el puente entre la capacidad técnica y el retorno de inversión (ROI).
¿Qué diseñamos específicamente para «llegar a buen puerto»?
Para resolver la fricción entre los tres perfiles, el trabajo de UX/UI se centró en tres pilares de diseño avanzado:
- Arquitectura de Información Basada en Contexto: En lugar de una estructura lineal, diseñamos una Navegación Condicional. Mediante el uso de variables de contexto y la función User(), la aplicación detecta quién inicia sesión y adapta el sitemap completo. No ocultamos botones; transformamos la experiencia de una «App de captura» (para campo) a una «Consola de control» (para oficina).
- Sistemas de Diseño sobre Power Apps: Para garantizar la agilidad sin perder la estética, creamos un mini-design system de componentes reutilizables. Esto permitió que, aunque las vistas fueran distintas para el Operativo y el Supervisor, la identidad visual y la usabilidad fueran consistentes, reduciendo la curva de aprendizaje.
- Diseño para la Incertidumbre (Modo Offline): Para el Usuario Operativo, el diseño UI incluyó indicadores visuales de estado de conexión y una gestión de errores proactiva. Diseñamos pantallas de «Sincronización Pendiente» que daban tranquilidad al usuario de que su trabajo no se perdería, algo vital en entornos de conectividad inestable.
Refinando la UX para un cliente de Raona
Trabajar con clientes de alto perfil en Raona exige que la solución no solo funcione, sino que sea robusta. Mi intervención como UX Designer incluyó:
- Micro-interacciones para la Integridad de Datos: Diseñé estados de validación visual inmediata (en lugar de esperar al botón de «Enviar»). Esto evitó que el Supervisor tuviera que corregir errores manuales a posteriori, saneando el dato desde el origen.
- Jerarquía Visual para la Toma de Decisiones: En la vista del Supervisor, aplicamos técnicas de Data Density. Usamos galerías con agrupaciones lógicas y códigos de colores (semáforos) para que, de un vistazo, pudiera identificar qué registros necesitaban atención inmediata, optimizando su tiempo de gestión en un 40%.
Diseñar para grandes clientes nos enseña que la tecnología es el medio, pero la empatía es la herramienta de desarrollo más poderosa. En este desafío con Raona, demostramos que cuando el UX/UI se antepone a la arquitectura técnica, el resultado no es solo una app que funciona, sino una solución que la gente elige usar. Por lo tanto, la próxima vez que alguien te pida ‘algo rápido en PowerApps’, acordate: la simplicidad técnica sin diseño es, casi siempre, una deuda técnica con el usuario.
