Caso de estudio | UX / UI · IA · Producto público
Digitalizar el proceso de licitación con una plataforma impulsada por IA
Diseñé el prototipo funcional de una plataforma con IA para la gestión de contratación pública, como parte de la propuesta técnica de Sciling al Ayuntamiento de Móstoles.
Rol
Product Designer
UX, UI y diseño de interacción con IA
Equipo
3 personas
1 Designer · 2 perfiles de negocio (asesoramiento de dominio)
Duración
1 mes
Julio - Agosto 2024
Herramientas
Figma
Research · Prototipado · IA
TL;DR
Entiende el proyecto en 3 claves
01
CONTEXTOSciling se presentaba a una licitación pública para desarrollar una plataforma con IA. El prototipo no era un añadido más; formaba parte del argumento técnico de la propuesta.
02
ACCIÓNAprendí el dominio de la contratación pública en tiempo récord para traducir requisitos legales complejos en flujos de usuario claros, diseñando una experiencia donde la IA automatiza sin quitar control al usuario.
03
RESULTADODiseñé un prototipo end-to-end que cubre todo el proceso licitatorio, integrando la IA en puntos críticos con trazabilidad, control del usuario y decisiones auditables.
Contexto
Diseñar un producto que tenía que convencer antes de existir
Sciling participaba en una Asociación para la Innovación convocada por el Ayuntamiento de Móstoles para desarrollar una plataforma que automatizara la gestión de licitaciones públicas mediante IA.
El prototipo tenía un papel clave: no era solo una visualización, sino parte del argumento técnico de la propuesta. Tenía que demostrar que la solución era viable en un entorno donde cada decisión tiene implicaciones legales.
Comprender la burocracia para no perder rigor legal
En contratación pública cada fase sigue un orden estricto, cada documento tiene un nombre específico y cualquier error puede derivar en impugnaciones. El técnico municipal que usa esta plataforma trabaja bajo responsabilidad legal y no puede permitirse que el sistema haga algo que no entiende.
La tensión central era clara desde el inicio: automatizar lo suficiente para reducir carga operativa y diseñarlo adecuadamente para no introducir opacidad o convertir el sistema en una caja negra.
Con un plazo de un mes, eso implicaba entender el dominio lo suficiente como para no simplificarlo en exceso. Analicé los pliegos a los que nos postulábamos y otros de referencia, para entender su estructura, y descompuse el proceso apoyándome en el equipo de negocio hasta poder mapear el flujo completo antes de comenzar a conceptualizar el diseño del producto.
Decisiones de producto y UI
Cómo traducir la complejidad legal en una experiencia usable
Traducir un proceso legal a una herramienta usable no era solo una cuestión de interfaz. Implicaba decidir cómo debía funcionar el producto en su conjunto.
La primera decisión fue alejarse del modelo habitual de gestor documental. En lugar de organizar la información en módulos independientes, el producto se plantea como un flujo guiado que refleja el orden real del proceso: el usuario avanza paso a paso y no puede saltarse fases, pero en todo momento puede ver dónde está y volver a pasos anteriores. Por la naturaleza del proceso, se hizo un requisito que la progresión fuese secuencial.
Esta estructura se vuelve especialmente relevante en tareas como la generación de pliegos. El sistema no se limita a mostrar formularios, sino que acompaña todo el proceso: desde la introducción de datos hasta la generación del documento, su edición externa y su posterior reintroducción en el flujo. En lugar de intentar sustituir herramientas habituales para ellos como Word, se integran como parte natural del trabajo. No es una concesión, sino una decisión consciente de diseño.
A partir de ahí, la navegación se diseñó como un sistema orientado a estado. En todo momento, el usuario puede ver en qué punto se encuentra, qué ha completado y qué queda pendiente. En un proceso largo y secuencial, esta orientación constante resulta más útil que cualquier menú tradicional.
Otra decisión clave fue no ocultar el lenguaje legal. Simplificarlo habría reducido la complejidad aparente, pero también habría eliminado precisión. En su lugar, se mantuvieron los términos técnicos, organizados y presentados de forma que se pudieran usar sin fricción.
Interacciones clave que resuelven trabas normativas y guían al técnico municipal.
Diseño de interacción con IA
El equipo técnico desarrollaba los algoritmos; mi trabajo fue diseñar el momento en que el usuario se encuentra con esa tecnología: cómo se presentan los resultados, cómo se deshacen acciones y cómo se garantiza la trazabilidad de cada paso automático para evitar la sensación de “caja negra”.
Transparencia algorítmica
Convertimos el requisito de “justificar adjudicaciones ante posibles impugnaciones” en un problema de diseño y jerarquía de información: resultado numérico destacado, justificación textual inmediata y desglose detallado bajo demanda.
Adaptación del DS Jotty
Se ajustó la librería visual y tipográfica existente, reformulando patrones pensando en perfiles con habilidades digitales dispares. El objetivo no era innovar visualmente, sino reducir fricción en interacciones complejas.
Arquitectura multirol
El sistema contempla tres perfiles de acceso (administrador, responsable de licitación y revisor) con interfaces adaptadas a cada uno. Definir esa separación desde el principio fue vital: en un entorno legal, quién puede hacer qué no es algo que se resuelva a posteriori.
IA en el producto
Diseñar con IA no es diseñar la IA
El pliego definía qué tenía que hacer la inteligencia artificial y el equipo técnico decidía cómo implementarla. Mi responsabilidad era diseñar la capa de experiencia que hace que esos resultados sean comprensibles, controlables y auditables por los técnicos municipales que los reciben. La IA estaba presente en múltiples puntos del proceso, pero el verdadero reto no era técnico, sino de experiencia: cómo presentar resultados generados automáticamente de forma que generasen confianza en lugar de incertidumbre. La premisa del diseño es hacer que el sistema proponga, pero nunca decida por el usuario. Esto se traduce en una secuencia consistente en todo el producto, donde cada resultado puede revisarse, modificarse y validarse explícitamente antes de darse por cerrado.
Control
El botón "Rehacer" está siempre visible en todos los resultados generados, y los campos se bloquean solo cuando el usuario ha completado el ciclo entero. El sistema nunca da por cerrado algo que el usuario no ha cerrado explícitamente.
Input
En al menos cuatro puntos del flujo aparece el mismo campo: "¿Algo que quieras resaltar? Escríbelo y el sistema lo tendrá en cuenta." Decidir incluirlo, y formularlo así, fue una decisión sobre quién controla el contexto que recibe la IA.
Transparencia
El resultado de la valoración técnica lleva porcentaje de adecuación, justificación textual y desglose por empresa bajo demanda. Mostrar el razonamiento, no solo el veredicto, responde a un requisito legal resuelto como problema de jerarquía de información.
El sistema muestra quién gana, por qué, y el detalle del proceso de selección — trazable y auditable.
Resultados
Un prototipo navegable para una propuesta real
En un mes diseñé la experiencia e interfaz de un producto completo en un dominio desconocido, cubriendo el proceso licitatorio de extremo a extremo y conectando más de veinte pantallas en un flujo coherente.
El prototipo tenía el potencial para demostrar que era posible automatizar partes críticas de un proceso con implicaciones legales manteniendo al usuario informado, en control y con capacidad de revertir cada paso automático.
1 mes
Para diseñar un producto end-to-end en un dominio desconocido
3 fases
Del proceso licitatorio cubiertas con más de 20 pantallas
1 DS
Adaptado, no construido desde cero, liberando tiempo para los flujos críticos
Flujo completo de la creación de una licitación mediante la plataforma.
Aprendizajes
Lo que aprendí
Diseñar en un dominio desconocido, bajo presión de tiempo y con marcos legales estrictos dejó aprendizajes que no se consiguen en otro tipo de proyecto.
01
Entender el contexto y la tecnología es parte indispensable del diseño
Tuve que entender la contratación pública en paralelo a las decisiones de interfaz. Reafirmé que es clave identificar rápido qué necesitas entender para no cometer errores con consecuencias, y qué puedes aprender sobre la marcha.
02
La IA debe ser explicada cuando el error tiene consecuencias reales
En un contexto como este, es más relevante que nunca que el usuario sepa qué está pasando. Diseñamos no solo la experiencia sino tambien la confianza, tratando con especial cuidado que la IA sea visible, explicada y facilmente revisable.
03
A veces el sistema que ya existe es la mejor decisión
Construir el design system desde cero habría sido la decisión más visible y la menos inteligente. Reutilizar el de Jotty con adaptaciones me permitió concentrar el mes donde importaba. Saber cuándo no construir algo nuevo es apostar por el criterio.
Hablemos
¿Tienes un proyecto?
Estoy abierta a proyectos de diseño de producto, branding y colaboraciones que tengan sentido humano. Cuéntame en qué estás pensando.