Ohana — Framer para productos complejos
Un previsualizador de HTML con superpoderes para diseñadores que trabajan con agentes de IA en la terminal. Live reload, comentarios colaborativos entre diseñador y agente, sitemap y flujos de usuarios que se convierten en código y handoff a repos reales. Local, open source, sin nube.
Framer para productos complejos
Ohana nació de una fricción diaria: dirigir a un agente de IA desde la terminal y no tener un canal visual a la altura de lo que el agente construye. Las herramientas de diseño tradicionales no ven el código; el navegador no entiende el flujo de trabajo del diseñador. Ohana es esa pieza que faltaba — un previsualizador de HTML y de repos frontend con superpoderes, local, sin cuentas y sin nube, donde el diseñador decide y el agente construye en código real.
La app es el canal visual entre ambos: live reload al guardar, comentarios estilo Figma anclados a elementos que el agente lee y responde, tableros de flujo, un design.md como fuente de verdad del sistema de diseño, y handoff directo a repositorios reales.
Moka — del user flow al código
Moka es el lienzo de layout de Ohana. Se parece a FigJam pero es opinionado: nodos de página, modal, decisión y subflujo; regiones, secciones y componentes dentro de cada pantalla; y estados vacíos marcados como deuda visible de diseño. La diferencia es que el tablero no es un dibujo — se guarda como documentación viva en JSON que el agente lee y escribe. Con un clic, el flujo se exporta como prompt estructurado y el agente lo convierte en prototipo HTML o lo implementa en el repositorio con los componentes reales del design system.
Comentarios que el agente responde
El modo comentario funciona como en Figma: clic sobre cualquier elemento, un pin numerado queda anclado, y el hilo se abre al lado. La diferencia es quién está del otro lado — los comentarios viven en un archivo JSON junto al prototipo, el agente los lee vía MCP, responde en el hilo y resuelve. La revisión de diseño se vuelve una conversación asíncrona entre el diseñador y su agente.
design.md — la fuente de verdad
Cada proyecto tiene un design.md con tokens, principios, voz y tono, patrones y un log de decisiones. Se edita en la app con un editor WYSIWYG real, y el agente lo consulta antes de tocar la UI y lo mantiene actualizado. Es la memoria compartida del sistema de diseño: libre en prototipos HTML, restringida a variantes cuando se trabaja sobre el design system del repo.
El ciclo completo
Flows Moka
La construcción de interfaces con AI está dejando algunos puntos ciegos por la velocidad de construcción, el objetivo de los flujos Moka es permitir que el control de la experiencia se tenga desde la experiencia y la tarea sin darle la responsabilidad de la memoria del diseñador del flujo. Un agente puede interpretar esto con un parseo del flujo y llevarlo a experiencias que resuelven problemas completos, y aqui es donde el criterio del diseñador aporta más valor al identificar dónde y cómo se despliega una experiencia.
Prototypes
Para Ohana un prototipo no está definido en un solo artefacto, puede venir de cualquier elemento que exista en la nube o en local y aquí en donde Ohana despliega sus herramientas para dar más poder de contexto visual a la experiencia.
Disminuir la fricción para no dev
Lanzarse a desarrollar así sea con agentes implica conocer términos y lógicas que aunque básicas generan fricciones, tal vez, innecesarias para los equipos de diseño.
Ohana interpreta el repositorio y sugiere los comandos y puertos para levantar ambientes locales y empezar a construir.
Ohana usa 4 herramientas clave para interactuar con el codigo - El input siempre se orquesta con un agente (claude code, codex, agy etc.) es agnóstico al agente por que no usa un API para funcionar, usa en cambio el contexto, skills y pluggins que se tengan definidos para interactuar
Terminal
Lanza cualquier agente y ohana ya tiene referenciada la carpeta donde vivirá todo el proyecto
Comentarios
Se puede ir revisando el resultado y dejando comentarios a medida que se audita la interface, luego el MCP permite volverlos tareas para el agente, resolviendo y comentado.
Componentes
Ohana intercepta y rastrea los componentes del proyecto en ambiente local, ahora ya los componentes de los sistemas de diseño en el código no dejan la interacción ciega o ambigua, mejor para reutilizar código que ya tiene el proyecto
Lo que aprendí construyéndola
Saber que responde en BE
Ese es un punto ciego durante mi proceso, desconocer el detalle de la respuesta de un API puede hacer que la información no sea la necesaria. Esto también lleva a diseñar pesando en el producto y su tecnología, ya sea por cubrir posibles gaps o evitar perder información
Handoff
Ohana no propone un framework para trabajar, de adapta al trabajo, un handoff para Ohana es una carpeta con contenido de archivos .md que son generados por skills propios de diseño para mi caso se utilizar un flujo de match en 4 fuentes de información .
Prototipo + Flujos
Repositorio FE objetivo
Repositorio BE objetivo
Sistema de diseño
/ejemplo
Handoff 1 — Filtros en la vista de incidentes
Prototipo: handoff-1-filtros-incidentes.html — HTML acotado a esta épica (derivado de ../index.html → Anomalías → Gestión, barra "Filtrar / Ordenar / Guardados"). Lo atenuado en ese HTML no hace parte de esta entrega.
Fuente: sesiones Granola 30-jun-2026 (am: épicas y cambios de UI · pm: design review con ingeniería) + comentarios de Ohana.
Registro: Interno / Operation Center. Plataforma: Desktop (shell de OC).
Qué cubre: los filtros de la lista de incidentes en Gestión (Recurso, Tablero, Estado, Tipo, Fecha), su lógica de combinación, el multiselect por categoría y los filtros guardados reutilizables.
Qué NO cubre: el editor de notificación y su alcance "Entidades afectadas", los paquetes de notificación y el resumen consolidado (todo eso es Handoff 3); la configuración de detección y las alertas del KPI (Handoff 2). La severidad no entra en scope (system-assigned, ver más abajo).
--------------------------------------------
Mapeo a componentes desyk (@simetrikinc/desyk-components)
Refs: fe-solutions-mf/.../skills/desyk/references/.
PATRÓN DEL PROTO COMPONENTE DESYK NOTA
Menús de Filtrar / Ordenar / Guardados Popover
Tooltip de íconos Tooltip para el botón "Guardados" icon-only y demás íconos
Multiselect por categoría / chips aplicados Combobox + render de chips desyk no tiene token-input dedicado; Combobox con búsqueda + chips custom
Estado / severidad como chip Badge (variants success/warning/info/destructive) severidad no se filtra, pero puede mostrarse como badge en la tarjeta
Botón icon-only ("Guardados") Button con size=icon-* requiere aria-label + Tooltip
---------------------------------------------
Historia de UX — HU-1 · Filtrar incidentes por varios valores y guardar ese filtro
Usuario: operador que revisa la cola de incidentes varias veces al día.
Contexto: entra a Gestión con una pregunta concreta ("¿qué hay confirmado en Adquirencia hoy?"); no quiere rearmar el filtro cada vez.
Historia: como operador que vuelve a la misma vista todo el día, quiero acotar los incidentes combinando varios valores y guardar esa combinación con un nombre, para entrar directo a "lo mío" sin reconstruir el filtro y sentir que la herramienta me conoce.Integración con agentes
Ohana incluye un servidor MCP sin dependencias: más de veinte herramientas para que cualquier agente compatible gestione comentarios, lea y escriba el design.md, y construya flujos de Moka programáticamente. La app publica cuál prototipo está activo, así el agente siempre sabe sobre qué está trabajando el diseñador.
Ohana es también un experimento sobre el rol del diseñador en sistemas agenticos: la diseñé, la especifiqué y la construí dirigiendo agentes de IA, usando el mismo flujo de trabajo que la app propone. Cada feature nació de una fricción real de mi día a día diseñando productos B2B densos. El principio que ordena todo: el diseñador decide, la IA expande, el diseñador filtra — y todo lo que el agente hace tiene que ser visible en vivo.