Dashboard de Instituciones
El panel donde una institución opera su suite de IA. Doc, el tutor de los estudiantes, y el Asistente Instruccional de los profesores viven dentro del LMS; aquí se configuran, se miden y se convierten en evidencia. Lo diseñé desde cero con stakeholders, desarrollo y data.
⌐ LAS DEMOS SON RECONSTRUCCIONES INTERACTIVAS — EL PROTOTIPO REAL, AL FINAL DEL CASO
La suite vive en el LMS. La institución opera desde aquí.
Para estudiantes y profesores la suite es invisible: trabaja dentro del campus virtual que ya usan, cero fricción. La institución que contrata necesita lo contrario: una superficie propia donde ver la adopción, administrar sus accesos y llevarse evidencia. El dashboard nació junto con la suite para ser esa superficie.
¿Y qué muestra? Intención, no calificaciones. El eje del reporte son los cinco modos de uso: no es lo mismo preguntar por transformaciones lineales para aprender, que hacerlo la noche antes del examen. Es el donut al centro del tablero de abajo.
Dos campos, cuatro verificaciones — el LMS hace el resto.
La conexión es LTI 1.3: Canvas, Moodle, Blackboard, Brightspace. En el onboarding de tres fases la institución da dos datos, la URL del LMS y el identificador de despliegue. La conexión se prueba a sí misma con cuatro verificaciones en vivo: identidad LTI, token de autorización, lectura del roster y latido de la API.
Por esa conexión fluye el sistema completo: los contextos de LTI alimentan la reportería, y los sílabos alimentan el conocimiento de Doc.
Cada rol entra a un panel distinto.
Quién entra al panel es una cosa; cuánto ve, otra. Lo primero lo define el producto; lo segundo lo administra la propia institución desde el módulo de Usuarios, sin depender de uDocz. Asigna admin, editor o profesor, con secciones específicas o todas.
- El director opera la institución completa: usuarios, reportes de todas las secciones, evidencia en PDF con membrete para acreditación, y el encendido y la audiencia de la comunicación. Lo único que no toca es el contenido de la IA: la personalización de Doc la ve como resumen de solo lectura, con "Solicitar edición" a un click.
- El editor trabaja sobre un grupo de secciones. Los segmentos, colecciones de secciones con nombre, le evitan armar el mismo filtro cada vez: uno solo filtra todo el panel.
- El profesor entra desde el LMS, junto a sus demás herramientas, y el panel se acota solo: reportes y vistas de sus secciones, nada nuevo que aprender.
- El equipo de uDocz ve y configura todo desde el Admin Hub, una consola aparte que el cliente nunca ve.
uDocz configura; la institución ve el resumen.
La personalización es trabajo del equipo uDocz: configura cada asistente, el de estudiantes y el de profesores, desde un hub con cuatro pestañas. El director no edita: ve un resumen de solo lectura con lo configurado y un botón "Solicitar edición". El contexto de un bot que acompaña estudiantes es delicado, y quien lo escribe es quien sabe cómo responde el modelo.
- General es la identidad: nombre y avatar, los modos de uso que se pueden activar, consentimiento informado e idioma por curso. La base es español y los overrides son la excepción, en un acordeón que aguanta más de mil secciones. Cierra con las instrucciones adicionales: prompts amplios que redacta uDocz — tono, integridad académica, citación de fuentes.
- Conocimiento es el contexto, la parte clave. Integraciones (Drive, Zoom, el SIS de la institución), formatos que puede leer, sitios web permitidos, documentos propios como reglamentos y manuales, y reglas abiertas específicas de la institución.
- Escalamiento: cuando la conversación toca temas socioemocionales, Doc deriva a un humano, con mensaje de derivación editable y un contacto responsable.
- Acceso: dónde vive el asistente (el LMS instalado, o embebido por URL en cualquier sitio) y por qué canales habla.
La mitad derecha es un preview en vivo que replica el chat como se ve embebido en el LMS, con el color de la institución inyectado. Dos reglas sostienen ese panel. El azul se reserva para CTAs y switches: es el único estado con color, los seleccionados van en neutro. Y todo lo binario es una fila con switch; el checkbox queda solo para selección múltiple.
La personalización empezó con siete pestañas; hoy son cuatro. Los tres recortes, cada uno con su razón registrada, están al final del caso.
Especificado en texto, entregado como prototipo navegable.
El panel existe en dos formatos. Como 28 documentos: cada módulo separa su documento de producto (qué es y por qué) del técnico (cómo se comporta), con los wireframes dibujados en ASCII dentro de la misma spec. Y como un prototipo navegable en HTML, CSS y JS sin framework, con datos sintéticos. Ese prototipo es el handoff: desarrollo no lee una imagen, abre la vista.
Consume el design system como submódulo fijado a una versión, con una capa puente declarada temporal. Las variables viejas del dashboard apuntan a tokens canónicos para no reescribir siete mil líneas de CSS de golpe; el puente se achica en cada release.
El mismo formato sostiene la iteración. Una etapa cierra con el visto bueno de dirección y queda congelada en una rama de archivo. La auditoría que sigue se hace sobre el prototipo navegable, producto funcionando y no mockups, y cada comentario entra como su propio PR. Quien quiera saber por qué algo cambió, lo lee en el historial.
Lo que se fue quedando en el camino.
Iterar también es soltar, como en todo producto, siempre con desarrollo y dirección en la mesa. La pieza con más historia es "riesgo": tres versiones de la misma pregunta (¿cómo le va a este alumno?), cada una más honesta con los datos disponibles. La demo cuenta las tres.
Lo demás, en corto:
- Facultad, programa y modalidad como campos de reportería: el LMS no los entrega; la vista se rehizo con lo que sí llega.
- Tres pestañas de la personalización: Mensajes prometía control sobre textos que genera el modelo; Comportamiento y Reglas eran instrucciones disfrazadas de controles; hoy se escriben en General.
- El dark mode: 238 reglas a revisar en cada cambio, para un panel que se usa de día. Archivado en su rama.
- El módulo de feedback: el KPI de satisfacción respondía lo mismo con menos superficie.
El prototipo real, vista por vista.
Las demos de arriba están reconstruidas para contar el diseño. Esto es el prototipo tal cual corre: seis de sus quince vistas, con data sintética. Click para abrir en grande.
