Case study
SEWDEF — una plataforma de inspección de alcantarillado que aprendió a confiar en su propia IA
INLOC Robotics analiza el estado de las redes de saneamiento a partir de vídeo, usando IA para detectar defectos automáticamente. Rediseñé el sistema de diseño y la plataforma SEWDEF para tres audiencias muy distintas que dependen del mismo dato: el equipo interno que valida lo que detecta la IA, la administración del negocio, y el cliente final que necesita entender, de un vistazo, el estado de su infraestructura.
Overview
Una IA que analiza vídeos de saneamiento, y tres roles que necesitan cosas distintas de ella
INLOC Robotics graba inspecciones en vídeo del interior de las redes de saneamiento. Esos vídeos se suben a SEWDEF, donde una IA interna los analiza automáticamente para detectar defectos (grietas, obstrucciones, raíces, pérdidas de visibilidad), generando etiquetas a lo largo del vídeo, métricas y un informe de estado por tramo. El encargo era rediseñar la plataforma completa, desde el sistema de diseño hasta cada pantalla, para tres roles con necesidades muy distintas sobre la misma base de datos.
Cliente (User): necesita ver el estado de sus inspecciones y descargar informes, sin entrar en el detalle técnico de cómo se generaron.
Analista QA: revisa cada vídeo, valida lo que ha detectado la IA o lo marca como duda si no está seguro.
Admin: gestiona contratos, empresas cliente, equipos y el estado global del pipeline de procesamiento.
El reto
Tres problemas que no se resolvían añadiendo más pantallas
Un mismo dato, tres lecturas distintas
El equipo interno necesitaba una interfaz densa, técnica, capaz de sostener un estándar de inspección europeo con decenas de campos por defecto. El cliente necesitaba justo lo contrario: un resumen legible sin tecnicismos. Diseñar una sola pantalla "para todos" habría sido peor para ambos.
Confiar en una IA que se puede equivocar
La IA detecta defectos, pero también se equivoca: clasifica mal, pierde referencia de distancia, tiene dudas. El sistema necesitaba un lenguaje visual para distinguir con claridad lo que es un hecho confirmado por una persona de lo que todavía es una hipótesis del modelo, sin frenar el ritmo de trabajo del analista.
Construir rápido sin perder consistencia
La plataforma existente no tenía un sistema de diseño real: cada pantalla nueva se construía desde cero, y el equipo de desarrollo no tenía forma de saber qué componentes eran fiables y cuáles seguían en construcción.
El punto de partida
De una plantilla de administración genérica a un producto con identidad propia
Cuando INLOC Robotics me contrató, la empresa no tenía diseñador: cada decisión de interfaz la implementaba directamente un desarrollador front-end, sin un proceso de diseño detrás. Me contrataron específicamente para rediseñar toda la plataforma y hacerla más útil e intuitiva. El resultado de esos años sin diseño era previsible: una plantilla de admin genérica, iconos por defecto, jerarquía plana, botones sin etiquetar. El dato de fondo (códigos de defecto, distancias, estados) ya era correcto; lo que faltaba era una forma de leerlo. Estas capturas son reales, de la versión anterior a mi rediseño (datos de cliente difuminados por confidencialidad).
Gráficos de estado ilegibles a ese tamaño, botones de icono sin etiqueta, sin relación visual entre el vídeo y los datos.
Condition Grading: la misma información (estado por defecto) convertida en un mapa de calor legible en un vistazo.
Una tabla sin priorización visual: carga de trabajo, plazos y dudas mezclados sin jerarquía.
KPIs de carga arriba, tabs de estado, y acciones directas por fila: la misma tarea, con prioridad clara.
Un formulario plano, sin guía de pasos y sin ningún manejo visible de errores.
Un asistente guiado, con creación inline de proyecto/perfil y 18 casos de error mapeados antes de construirlo.
El enfoque
Empezar por entender el proceso, no por dibujar pantallas
Antes de abrir Figma en serio, necesitaba entender cómo funcionaba realmente la plataforma por dentro: el proceso completo desde que se sube un vídeo hasta que el cliente descarga su informe, y cómo trabajaban día a día los perfiles de Admin y QA. Solo con eso claro tenía sentido definir una arquitectura y empezar a diseñar.
Estructura interna
Estudio del proceso end-to-end (desde que se sube un vídeo hasta que se descarga el informe) y de cómo trabajaban internamente Admin y QA.
Análisis de competencia
Revisión de cómo resuelven este mismo problema otras plataformas del sector, para no partir de cero ni repetir sus errores.
Arquitectura
Definición del esquema de información: qué pantallas existen, cómo se relacionan, y qué necesita ver cada rol.
Wireframes
Primeras estructuras de pantalla en baja fidelidad, para validar flujos antes de invertir en visual.
Design System
Librería de +40 páginas de componentes en Figma, con tokens, estados y una etiqueta de madurez por elemento.
Diseño & testeo
Diseño de cada pantalla y validación con usuarios reales de la plataforma: analistas QA y clientes, no solo stakeholders internos.
Tokens con estado de madurez, no solo estilos
Cada token y componente lleva una etiqueta (Ready to use, Live in Prod o In dev) para que desarrollo sepa exactamente qué puede usar ya. No es solo un catálogo visual: es una herramienta de gobernanza compartida con el equipo técnico.
Una matriz de estados, no solo de estilos
Cada componente interactivo (botones, checkboxes, inputs, switches...) está documentado en todos sus estados (default, hover, pressed, disabled, error, read-only) y en modo claro y oscuro. La distinción entre "disabled" y "read-only" no es habitual en un design system, y aquí tiene sentido: un dato generado por la IA se muestra en read-only hasta que una persona lo confirma.
Decisión de diseño: los colores de acción (Primary/Secondary) están desacoplados del color de marca: el sistema soporta 5 paletas semánticas para poder reutilizarse en distintos productos de INLOC sin rehacer el sistema desde cero.
Componentes reales — pruébalos tú mismo
Con permiso de INLOC Robotics, esto no son capturas: son los componentes reales del sistema, reconstruidos con los tokens de color, radio y sombra exactos de la plataforma. Interactúa con ellos.
Selecciona el código de defecto según UNE-EN 13508-2.
La solución
Un recorrido por la plataforma, pantalla a pantalla
Con la base del sistema resuelta, esto es lo que construí encima: desde el primer login hasta el panel donde Admin decide quién puede tocar qué.
Acceso sin fricción, sin registro propio
Al ser una herramienta B2B, no existe un flujo de "crear cuenta": las cuentas las da de alta INLOC. Por eso el login sustituye el registro por un enlace a "Contáctenos", y el flujo de recuperación de contraseña se diseñó para resolverse en el menor número de pasos posible.
Mapa de flujo real usado para validar la lógica condicional con desarrollo antes del hand-off.
Un dashboard distinto para cada rol
La página de inicio cambia por completo según quién ha entrado: no es la misma pantalla con permisos ocultos, sino tres experiencias diseñadas para la tarea de cada rol.
Cada fila de la tabla completa (no mostrada aquí por confidencialidad de clientes) incluye dos acciones directas (🚩 marcar duda y ✓ validar) sin salir de la tabla ni abrir el vídeo, para los casos donde la clasificación de la IA es obviamente correcta.
Confirma la capa de negocio B2B detrás del producto: Admin gestiona Contratos, Empresas y Suscripciones, además de monitorizar el estado técnico de cada ejecución del pipeline de IA (Procesando, Terminado, Rechazado, Validación pendiente...).
De empresa a proyecto a vídeo: tres niveles de zoom
Los vídeos no viven sueltos: se agrupan en proyectos (por ejemplo, una campaña de inspección de un sector concreto), y cada proyecto agrega sus propias métricas antes de bajar al detalle de cada vídeo individual.
El resumen del proyecto agrega justo los datos que importan antes de entrar al detalle: longitud total inspeccionada, duración total y una barra de estados de un vistazo, con la misma jerarquía de estado que ya aparece en el resto de la plataforma.
Subir vídeos sin miedo a que algo falle
Subir vídeos parece una acción simple, pero el asistente tiene que sostener red inestable, archivos corruptos, plantillas mal rellenadas y usuarios que pertenecen a varios "sites" a la vez. Antes de esta pantalla mapeé el flujo completo en 4 etapas (Configuración previa → Selección y validación → Subida → Inicio de análisis), con su camino feliz y 18 casos críticos documentados.
El primer paso no es soltar archivos, es decidir dónde van a caer: proyecto y perfil son opcionales y se pueden crear sin salir del propio asistente, y el usuario puede descargar aquí mismo la plantilla Excel que luego usará para importar datos en bloque.
Fallo de red durante la subida
Se corta la conexión a mitad de subida → la subida se pausa, aparece un icono de "Reintentar" en el archivo afectado, y una alerta clara: "Se perdió la conexión. Comprueba tu red y pulsa Reintentar."
Cancelación individual
El usuario cancela un solo archivo de la cola sin afectar al resto → esa barra de progreso desaparece y el archivo vuelve a su estado inicial.
Errores fatales vs. recuperables
Formato incorrecto o archivo corrupto (fatal, hay que eliminarlo) frente a fallo de conexión (recuperable, se puede reintentar), cada uno con su propio tratamiento visual.
Salir sin analizar
El usuario cierra el asistente tras subir los archivos, sin pulsar "Iniciar análisis" → nada se pierde: los vídeos quedan catalogados como "Incompletos" o "Pendientes", listos para retomar después.
Sin 3 datos obligatorios, no hay IA
Para que la IA pueda procesar un vídeo, necesita tres datos del tramo que no puede inferir sola: tipo de inspección, material y geometría. Sin ellos, el vídeo se queda en la cola de "Inspecciones pendientes": visible, pero bloqueado.
Dos formas de rellenar los tres campos: uno a uno, con los enlaces "+ Añadir" directamente en la tabla, o de golpe con "Importar datos" desde un archivo Excel/CSV/TXT que el sistema mapea automáticamente a las inspecciones correspondientes.
Importación correcta
El archivo mapea bien los datos → los campos se autorrellenan y se habilita "Iniciar Análisis".
Formato no compatible
Archivo que no es CSV/Excel/TXT, o pesa más de 10MB → "Formato no compatible. Usa Excel, CSV o TXT".
Error de mapeo
El archivo es válido pero sus datos no coinciden con las inspecciones existentes → "No se han podido vincular algunos datos. Revisa la plantilla".
Subida múltiple
El usuario arrastra varios archivos a la vez → "Solo se permite subir un archivo por vez".
El corazón del producto: revisar, corregir y validar
La pantalla más importante de toda la plataforma. Aquí el analista revisa cada defecto que la IA ha detectado en el vídeo, comprueba si lo ha clasificado bien, añade los que falten o elimina falsos positivos, todo codificado según el estándar europeo UNE-EN 13508-2 de inspección de saneamiento, con código de defecto, caracterización, cuantificación y localización circunferencial (posición en la sección del tubo, tipo reloj de 24 posiciones).
Pensada para el trabajo de precisión sobre un defecto: el panel lateral trae todos los campos del estándar UNE, con vista previa del fotograma capturado.
Pensada para revisar todo el tramo de un vistazo: la tabla de los 33 defectos encontrados pasa a ser la protagonista, y arriba aparecen los metadatos técnicos del tramo editables sin salir de la pantalla.
Decisión de diseño: las dos vistas son dos modos de trabajo, no una redundancia. Vista 1 para cuando ya sabes qué defecto estás corrigiendo; Vista 2 para cuando estás escaneando el tramo entero. El botón Validar/Duda del topbar y el marcador naranja de cada defecto en el timeline se mantienen idénticos en ambas, para no perder el hilo al cambiar de modo.
El componente propio del proyecto: representa el estado de un tramo a lo largo de la distancia inspeccionada, no del tiempo de vídeo. Un tramo de 11 metros puede pasar de "Excellent" a "Failure" en cuestión de centímetros, y el analista lo ve antes de reproducir nada: funciona como mapa de calor de severidad.
La misma tabla, en modo lectura
El cliente ve exactamente los mismos defectos, códigos y distancias que revisó el analista QA, pero sin "Validar" ni "Duda": en su lugar, Edición Manual (para pedir un cambio puntual), Exportar y Copiar link / Compartir.
El panel derecho añade contexto que no está en la pantalla de QA: condiciones ambientales durante la grabación y datos de la canalización, pensado para un informe que alguien va a leer y exportar, no para trabajar sobre él fotograma a fotograma.
Decisión de diseño: quitar los verbos de trabajo de la vista de cliente no es solo simplificar: es dejar claro con la propia interfaz que este dato ya ha sido revisado y cerrado por el equipo técnico. El cliente consulta y exporta; no edita el criterio técnico.
Cuando la IA se equivoca: el sistema de confianza humano-IA
Ningún resultado de la IA se da por bueno automáticamente. El botón Validar / Duda del topbar QA es la decisión de diseño que sostiene todo el flujo de calidad: cada detección queda marcada como pendiente de revisión hasta que una persona la confirma o la escala.
Cuando la IA detecta saltos en su propia estimación de distancia, no lo oculta: muestra los tramos afectados en una tabla editable para que el analista los corrija antes de aprobar el informe.
Cuando un analista marca una "duda", se abre un ticket con prioridad y una referencia al minuto exacto del vídeo. El supervisor lo resuelve y el analista recibe la notificación de vuelta, cerrando el bucle de confianza.
Aquí se cierra el círculo: Admin ve cuántas horas lleva cada analista, reasigna vídeos con plazo próximo a vencer, y ve qué vídeos tienen una consulta Abierta o ya Resuelta, la misma columna que dispara la notificación de "revisión finalizada" que ve el analista.
Quién puede tocar qué
Cada perfil tiene su propia pantalla de cuenta (información personal, preferencias, seguridad), pero el campo Rol aparece siempre en modo lectura: el sistema lo asigna, la persona no puede cambiárselo a sí misma. Por encima de los equipos, Admin gestiona todos los usuarios del sistema y todas las empresas cliente con sus contratos, suscripciones y paquetes.
Cuatro roles y cuatro estados de cuenta, incluyendo "Pendiente" con su propia acción (Reenviar petición) para cuando una invitación caduca antes de aceptarse.
Cada empresa cliente tiene su propia ficha con KPIs de uso y cuatro pestañas (Contratos, Suscripciones, Paquetes, Usuarios), confirmando que una misma empresa puede tener varios contratos y paquetes activos a la vez.
Resultado e impacto
Un sistema de diseño con gobernanza, aplicado a tres experiencias reales
- Una librería de más de 40 páginas en Figma (fundamentos, componentes y patrones), con estado de madurez documentado por elemento. Hoy sostiene el portal de cliente, la cola de trabajo de QA y el panel de administración sobre la misma base visual.
- Arquitectura de navegación y home independientes para User, QA y Admin sobre la misma base de datos, sin triplicar el backend.
- Un flujo Validar/Duda con sistema de tickets que cierra el bucle de confianza entre la IA y el equipo humano, sin frenar el ritmo de revisión.
- Más de 20 casos límite documentados (subida de archivos, importación de datos, inspecciones pendientes) antes de pasar a desarrollo, reduciendo retrabajo en la fase de implementación.
- Un componente propio, Condition Grading, que traduce el estándar técnico UNE-EN 13508-2 en una lectura visual inmediata del estado de un tramo.
Más allá de la app: también diseñé y construí en WordPress la web comercial de SEWDEF, el primer contacto de un cliente potencial con el producto, antes incluso de pedir una demo. Ver ese proyecto →
Aprendizajes
Lo que me llevo de este proyecto
Diseñar para una IA que se equivoca es diseñar para la confianza, no para la automatización
El reto real no era "cómo mostrar lo que detecta la IA", sino "cómo dejar claro qué es definitivo y qué no". Eso se resolvió más con estados (read-only, pendiente, validado) que con copy o con avisos puntuales.
Un estándar técnico puede convertirse en ventaja de producto si se traduce bien
Meterme en el detalle de cómo se clasifican los defectos de saneamiento (UNE-EN 13508-2) fue lo que hizo posible diseñar Condition Grading, no al revés. El componente más distintivo del proyecto nació de entender la norma, no de una lluvia de ideas visual.
Gobernar un design system importa tanto como construirlo
La etiqueta de madurez (Ready to use / Live in Prod / In dev) nació de ver que desarrollo perdía tiempo adivinando qué podían usar ya. Ese pequeño cambio de proceso ahorró más fricción real que cualquier componente nuevo que diseñé.