Volver a proyectos
Caso de estudio · Safe Intelligence

Spec27: una plataforma de validación de IA hecha por ingenieros, puesta en claro.

Safe Intelligence construyó Spec27 para validar agentes de IA sin que cada equipo tenga que montarse su propia infraestructura de pruebas. La ingeniería era sólida; la interfaz peleaba con sus usuarios. En North dirigí el rediseño completo: investigación, estrategia, marca, todas las pantallas y el kit listo para desarrollo desde el que ingeniería lo implementó.

En producción. El relanzamiento atrajo más de 500 registros en su primera cohorte.

De vacío a vivo: la consola rediseñada, en producción
01 · Problema
01

El problema, y lo que encontramos

Antes de diseñar una sola pantalla, mapeé el terreno: cómo se organizan consolas análogas, qué era el producto por dentro y con qué tropezaban sus usuarios una y otra vez. El material del propio cliente (hilos del repositorio, Looms) se procesó con IA para ganar velocidad y se cruzó con mi auditoría. Todo aterrizó en un único documento de feedback que alineó a cliente y equipo sobre qué estaba roto.

escaneo competitivo 6 consolas auditoría de producto muestra anotada mapa conceptual el modelo real documento de feedback problemas, priorizados github repo looms /ai-digest CLIENT UX luz verde prototipo material de cliente procesado con IA para ganar velocidad: el documento alineó a cliente y equipo antes de diseñar una sola pantalla
Render Color que guía decisiones; patrones de tratamiento OpenAI Arquitectura reconocible sobre un DS a propósito genérico Latitude Cómo separan web y producto; sus flujos de onboarding Cala El aire orgánico y humano de LLM, estudiado y descartado Anthropic Confirmó que la vía orgánica no era la nuestra Galtea Competidor más cercano: componentes, color, AI, formularios, modales el lenguaje de consola de Spec27 discontinuo: vía estudiada y descartada · violeta: el competidor más cercano

Cinco hallazgos

01
La navegación no encajaba con el modelo.

La estructura peleaba con la forma real de pensar del producto: proyectos, agentes, especificaciones y evaluaciones estaban dispersos en vez de relacionados.

02
Una interfaz rudimentaria.

Inconsistente, anticuada y poco accesible, con componentes que se comportaban distinto en cada página.

03
Una marca con la que no se podía trabajar.

Los modos claro y oscuro no se ponían de acuerdo; el logo no tenía aplicación para ninguno. Nada sobre lo que construir pantallas. (Hasta se llamaba de otra forma: DeepScan.)

04
Sin estados vacíos.

Los usuarios nuevos se encontraban tablas en blanco: el producto en su momento más vacío justo cuando más necesitaba explicarse.

05
Complejidad sin guía.

Lenguaje muy técnico, sin onboarding y sin un camino visible hacia un primer resultado.

02 · Fases
02

Dos plazos, dos fases

Dos fechas inamovibles marcaron todo el proyecto: un evento del cliente a pocas semanas y un relanzamiento después. Así que el trabajo se partió en dos: primero una victoria rápida y quirúrgica, después el rediseño de verdad.

el evento: presentación y tests con usuarios relanzamiento · +500 registros fase 1 · victoria rápida fase 2 · rediseño completo pausa siguiente ciclo MAR ABR MAY JUN JUL AGO SEP rondas de feedback fechas aproximadas, reconstruidas a partir de los artefactos del proyecto

Fase 1 · la mejora rápida

Tres puntos de contacto reestructurados sin tocar la marca: la portada, la vista general de cada proyecto y una primera pasada de navegación y barra superior. Claridad suficiente, y a tiempo, para que el cliente presentara en el evento y probara con usuarios sobre algo que se sostenía. El resultado fue cualitativo, y compró confianza para la fase 2.

Fase 1: el mismo producto, reestructurado El producto original, antes del rediseño AntesFase 1

Arrastra para comparar el mismo producto con semanas de diferencia. La fase 1 se quedó dentro de la marca antigua a propósito.

03 · Rediseño
03

El rediseño

La fase 2 fue la reconstrucción completa, sobre un flujo agéntico con personas en cada puerta. Los planes se convirtieron en design.md y roadmap.md; agentes de prototipo y de crítica producían y cuestionaban el trabajo; el cliente y sus ingenieros revisaban cada paso. La crítica vivía en el chat, la implementación y la auditoría en un agente de código, y la exploración en un agente de diseño.

Ejecución agéntica · plan Ejecución agéntica · construcción auditoría ux feedback del cliente mapa conceptual /plan design.md roadmap.md tasks.md /ux-prototype /ux-critique /batch-review prototipohtml kit para desarrollohtml · css · js implementación ENG 2 semanas relanzamiento Revisión humana UX CLIENT UX CLIENT UX ENG UX: yo · CLIENT: el product owner · ENG: el equipo de ingeniería del cliente crítica en chat · implementación y auditoría en un agente de código · exploración en un agente de diseño · nada sale sin revisión humana

Una marca que sí funcionaba

Dos semanas de branding ligero antes de las pantallas: una guía de estilo, un lenguaje de movimiento y el armazón del producto vistiendo la identidad nueva, con claro y oscuro por fin de acuerdo y un logo que funciona en ambos.

El armazón del producto con la nueva identidad de Spec27

El modelo corregido

La navegación solo tuvo sentido cuando lo tuvo el modelo. Un proyecto contiene tres objetos de primer nivel: agentes, especificaciones y las evaluaciones que los emparejan. Los datasets y los jueces pasaron a ser fontanería: se configuran cuando hacen falta y no se navegan nunca.

registro de organización agentes integrados · publicados copiar Proyecto agentes lo que validas especificaciones contrato versionable eval agente + spec ejecuciones → resultados Tres objetos de primer nivel.El usuario nunca vela fontanería. datasets · jueces: se configuran detrás, no se navegan

El giro: del asistente al bucle

A mitad de camino, la creación de especificaciones cambió de naturaleza. El propio prototipado del cliente mostró que los usuarios no configuran una vez y siguen: iteran entre un agente y su especificación hasta que se comporta. El asistente secuencial que estaba diseñando murió esa semana. En su lugar: un micro-asistente para lo esencial y después un bucle guiado dentro del editor, donde decide el usuario, no el formulario, cuándo la especificación ya es suficiente.

El plan · secuencial El rediseño · micro-asistente y bucle crear proyecto añadir agente crear spec crear eval ejecutar una sola dirección · el formulario decide cuándo has terminado “Los usuarios no loconfiguran una vez: iteranentre agente yspec hasta que funciona.” el bucle de feedback del cliente micro-asistenteproyecto · lo esencial editor de spec guiado · con onboarding borrador de spec ejecutar contra agente refinar agente de pruebasiempre disponible eval → ejecución ¿suficiente? decide el usuario 0→1 en 7 pasos crear una spec es ahora un bucle del que sales cuando la spec ya es suficiente

Diseñado por estados

Con el 0→1 definido, cada superficie principal se diseñó tres veces: vacía, con el primer proyecto y llena de datos. El estado 0 te lleva directo a tu primera especificación, con un agente de prueba integrado siempre disponible, para que la fricción de integración no bloquee nunca el camino.

Estado 0: el producto te guía para crear tu primera especificación Estado 1: primer proyecto configurado, todo cubierto Estado 30: la consola llena de ejecuciones y datos

Estado 0, todavía nada. La vista general se convierte en un onboarding: crea tu primera especificación.

Resultados: un átomo, tres miradas

Los resultados vivían dispersos en páginas que replicaban las de recursos: dos páginas de “Evals” y la robustez partida por tipo. El rediseño puso nombre al dato valioso, la ejecución de una especificación, y convirtió cada vista en una lente sobre él: agrupar por evaluación, por agente o por especificación; las filas se despliegan en su sitio; todo enlaza con todo.

Antes · agrupado por página Después · un átomo, tres miradas páginas de resultados páginas de recursos resultados de eval robustez de spec robustez de agente evals especificaciones agentes Cada tipo de objeto tenía una página de resultadosy otra de recurso: dos páginasde “Evals” y el dato partido por tipo. ¿dónde vive un resultado? depende ejecución de spec limpia → robusta · el átomo el dato que importa, el resto de vistas lo agregan Resultados: una página cada ejecución · solo lectura por eval por agente por spec rag agent · non-stream multi-turn agent google vertex rag agent ver ejecución #493 → los mismos átomos, reagrupados: nunca duplicados · enlaces cruzados por todas partes la solución no eran más páginas: era ponerle nombre al dato valioso (la ejecución de spec) y dejar que el usuario cambiara de lente
La página de Resultados consolidada: ejecuciones agrupadas por evaluación, agente o especificación

La página de resultados consolidada: un solo sitio, tres agrupaciones y cada fila enlazada.

Entregado como kit listo para desarrollo: HTML, CSS y JS. Ingeniería implementó la reconstrucción en dos semanas, a tiempo para el relanzamiento, algo que la vía convencional no habría permitido.

04 · Resultado
04

Resultado

Cuando el modelo es correcto, el producto se explica solo. El cliente cerró el ciclo contento y reservó el siguiente.

0pasos
configuración 0→1, antes ~30–40
0semanas
del kit al producto implementado
0+
registros en la cohorte del relanzamiento
0estados
cada superficie principal: vacía, primera, llena

Primera cohorte real: registros, todavía no activación. El siguiente ciclo empieza en septiembre.

Interactivo

No me creas. Ábrelo.

El rediseño completo funciona en tu navegador: entra, cambia entre los estados vacío, primero y lleno, y recorre el bucle de especificación y los resultados.

Abrir el prototipo
Vista previa del prototipo de Spec27
Más proyectos