City Home: de un cuarto vacío a la compra en AR, en nueve días
Una mueblería de Florida necesitaba mostrar, de punta a punta, cómo alguien escanea un cuarto vacío, lo ve amueblado en realidad aumentada y lo compra. Orquesté un proceso agéntico, del descubrimiento a la especificación para desarrollo, y en nueve días entregué 61 pantallas con prototipo, un sistema de 25 componentes documentados y un brain donde vivía cada decisión.
El prototipo no era una maqueta para impresionar. Era la definición de terminado para la ingeniería, y cada toque de más entre la persona y la compra se iba a convertir en trabajo de alguien.
City Home vende muebles en Florida. Junto a ImaageQ, que construye la tecnología, trabaja en una app de iPhone que escanea un cuarto, lo amuebla con piezas del catálogo y lo muestra en realidad aumentada. Entré al proyecto el 28 de septiembre de 2026 como product engineer y product architect, junto a un lead de producto y un equipo técnico externo que ya había construido la primera versión de la app y su motor de reglas.
Este caso cuenta tres cosas: la solución que entregamos, el sistema de diseño que la sostiene y, sobre todo, cómo orquesté un proceso agéntico de punta a punta para hacerlo en nueve días sin soltar las decisiones críticas.
El encargo y el giro
El encargo empezó por otro lado: una aplicación web interna para los diseñadores comerciales de City Home, las personas que convierten el plano y el pedido de un desarrollador inmobiliario en una propuesta amueblada con precios. Los primeros días fueron de descubrimiento. Revisé tres exploraciones de pantallas que ya existían y recomendé combinar el flujo de una con la distribución de otra, con un principio claro: un espacio de trabajo, no un SaaS más. También armé el inventario del producto, unas 36 páginas agrupadas en 12 flujos, un guion de prueba de usabilidad y las métricas para medir la experiencia.
El 2 de octubre cambió la prioridad. Hacía falta una demo de la app de iPhone de punta a punta: requisitos, escaneo, diseño en AR, canasta y pago. Y llegó con una regla de medida que guió todo lo que vino después: se cuenta en toques hasta la compra, y ninguno puede sobrar.
El brain: donde vivía cada decisión
Con un equipo repartido y decisiones que cambiaban de un día para otro, el riesgo no era diseñar mal sino olvidar por qué se había decidido algo. Por eso el proyecto tuvo un brain: un vault de Obsidian con una nota de inicio que dice dónde estamos y qué esperamos de otros, carpetas por tema que son el documento vivo y una carpeta por sesión con copias fijas de lo que se mostró ese día, en español y en inglés. Lo vivo nunca se mezcla con lo presentado.
Cada reunión se grababa y se transcribía. La nota recoge solo lo que se dijo, cierra con decisiones y compromisos, y lo que no se trató queda como «por definir». Las decisiones pasan a un registro con fecha y enlace a su origen, que llegó a unas 45 filas en nueve días. Y las reglas de diseño tienen una sola puerta de entrada: si algo no está en las reglas, se decide, se anota y después se aplica.
El brain también sirvió hacia afuera. El 1 de octubre, en una revisión, el lead de producto preguntó cómo estaban saliendo tantas pantallas tan rápido. La respuesta fue abrir el brain, y pidió que se lo compartiera.
Cómo orquesté a los agentes
El proyecto fue agéntico de punta a punta, desde el descubrimiento y la definición hasta la especificación para desarrollo. Los agentes ponían la velocidad; las decisiones críticas eran mías: los estilos, los comportamientos, la consistencia y que cada flujo quedara claro y completo.
Armé un equipo de tres agentes, cada uno con un frente:
- —Agente de UX. Generaba los flujos y las pantallas a partir de las reglas y las decisiones escritas en el brain. Yo las corregía una por una.
- —Agente de UI. Auditaba la consistencia entre pantallas y me ayudaba a componentizar y documentar el sistema, con lo necesario para implementar la app.
- —Agente de QA de diseño. Validaba los resultados y detectaba los vacíos entre los requisitos y lo que resolvía la interfaz. Lo que proponía quedaba «por validar» hasta que yo lo confirmara.
Mi trabajo era dirigir: escribir las reglas, decidir lo que un agente no debía decidir y no dejar pasar nada al entregable sin revisarlo. Una de esas revisiones retiró una pantalla entera, porque cambiar y aprobar el diseño tenía que pasar dentro del AR y no en una pantalla aparte.
La solución: seis toques hasta la compra
El flujo tiene siete pasos y una promesa: la sesión de AR nunca se rompe. La persona dice qué cuarto quiere diseñar, qué no puede faltar y cuánto quiere gastar; escanea el cuarto; el diseño aparece amueblado en AR; elige entre dos propuestas; ajusta una pieza; revisa la canasta y paga. Son 61 pantallas con prototipo, organizadas por tarea y no por número, cada una con una nota de experiencia debajo.
Los requisitos se alinearon con lo que el motor de reglas sabe hacer. Por eso el formulario no pide estilo, porque el motor no tiene datos de estilo, y los imprescindibles vienen preseleccionados según el tipo de cuarto. El usuario tampoco ve el lenguaje interno del motor: en lugar de reglas y conteos, lee «Fits your room».
Para editar una pieza sin salir del AR diseñé un disco radial: se toca la pieza y aparecen sus acciones alrededor, y un segundo nivel para el color. Mientras una pieza está en edición se ocultan los controles del layout, y solo un color lleva anillo a la vez. Quien quiera armar su propio diseño puede hacerlo desde un catálogo filtrado por lo que cabe en ese punto del cuarto.
La canasta es compacta: sin papelera, la cantidad a la derecha y eliminar deslizando, con Undo en lugar de un diálogo de confirmación. Apple Pay aparece solo en la canasta, como la única acción principal.
Cuando algo sale mal
Una demo que solo muestra el camino feliz no sirve como definición de terminado. Diseñé ocho pantallas de casos límite, como un color agotado, un cambio de precio, una generación que falla, la conexión perdida, el pago rechazado o la cámara desactivada, y documenté otros 16 casos en una tabla. Todo se rige por ocho reglas de interacción comunes a la app.
| Regla | Qué significa |
|---|---|
| El AR nunca se rompe | Las hojas se abren sobre la sesión de AR en vivo; al cerrarlas se vuelve al mismo cuarto sin recargar. |
| Una sola acción principal | Cada pantalla tiene un único botón primario; lo demás es secundario. |
| Material propio sobre la foto | Los controles sobre el AR llevan negro al 55 % con desenfoque o blanco al 90 %, con contraste de al menos 4,5:1. |
| Editar oculta el layout | Con el disco abierto o en modo mover, se esconden el selector de layout y la flecha. |
| Se paga solo en la canasta | Elegir un diseño nunca cobra; Apple Pay vive solo en la canasta. |
| Reversible, no confirmado | Quitar y eliminar actúan al instante y ofrecen Undo, sin alertas de confirmación. |
| Visible pero no disponible | Colores y piezas agotados siguen a la vista, tachados o en gris; nunca se ocultan. |
| 44 pt y 12 pt | Todo objetivo táctil mide al menos 44 × 44 y ningún texto baja de 12 pt. |
El sistema de diseño
Todo el archivo usa un mismo sistema. Las foundations tienen tres colecciones de variables: primitivos, tokens semánticos para fondos, texto, estados, materiales sobre la foto y la capa de AR, y dimensiones con espaciado, radios y tamaños táctiles. La tipografía es SF Pro con 11 estilos mapeados a SwiftUI y Dynamic Type, y nada baja de 12 puntos. La paleta es solo neutra, con una excepción: el rojo del sistema, reservado para eliminar.
| Token | Para qué se usa |
|---|---|
bg/default · bg/muted | Fondo de pantallas y hojas; fondos secundarios como campos y botones de ícono. |
bg/inverse | Botón primario y elementos de máximo énfasis. |
fg/default · fg/muted · fg/disabled | Texto e íconos principales, secundarios e inactivos. |
status/success | Confirmaciones: envío gratis, dentro del presupuesto, pedido hecho. |
status/destructive | El rojo del sistema, solo para deslizar y eliminar. La única excepción a la paleta neutra. |
material/on-photo-dark · -light | Controles sobre la foto o el AR, siempre con desenfoque. |
| Estilo | Tamaño / interlineado |
|---|---|
| Large Title | 34 / 41 Bold |
| Title 1 · Title 2 | 28 / 34 Bold · 22 / 28 Bold |
| Headline | 17 / 22 Semibold |
| Body | 17 / 22 Regular |
| Subhead · Footnote | 15 / 20 · 13 / 18 |
| Caption | 12 / 16, el mínimo |
Espaciado 4 · 8 · 12 · 16 · 20 · 24 · 32 · 40 — radios 6 · 10 · 14 · 24 · completo — táctil 44, botón 50, margen 16.
Sobre esas bases hay 25 componentes, entre átomos, moléculas y piezas de documentación. Cada uno trae anatomía, variantes, especificaciones, estados, qué hacer y qué no, accesibilidad y una nota para implementarlo en SwiftUI. El disco radial es un buen ejemplo del nivel de detalle.
| Grupo | Componentes |
|---|---|
| Átomos (12) | Button, Icon button, Apple Pay button, Qty stepper, Badge, Page dots, AR caption, Layout pill, Toast, Notice, Chip, Side button hint |
| Moléculas (9) | Radial menu, Arc item, Basket item, Layout toggle, Buy bar, Design option card, Catalog piece, Sheet header, Menu |
| Documentación del archivo (4) | Doc card, Row label, Section header, Screen tags |
Anatomía del disco radial
- Banda: un arco de 268 pt en blanco al 95 %, con los extremos redondeados.
- Atrás: vuelve al nivel anterior.
- Opciones: colores, acciones o piezas, según el nivel. La activa lleva anillo.
- Separador: una línea fina entre la navegación y las opciones.
- Confirmar: aplica el cambio y cierra.
| Nivel | Qué muestra |
|---|---|
| Acciones | Quitar, mover, cambiar, configurar y confirmar. |
| Colores | Atrás, los colores disponibles y confirmar. El activo lleva anillo. |
| Cambiar | Atrás, las piezas que caben en ese lugar y confirmar. |
| Rápido | Undo, colores y confirmar: el atajo dentro del AR. |
Se abre al tocar una pieza, con un resorte de 0,3 s desde ella. Al cambiar de nivel los elementos rotan con un fundido de 0,2 s y la banda se queda quieta. Se cierra con ✓ o tocando afuera, y el cambio queda aplicado en el AR.
La velocidad
Lo que salió en nueve días, del kickoff al handoff:
| Entregable | Cantidad |
|---|---|
| Pantallas con prototipo | 61, en 8 secciones por tarea |
| Componentes documentados | 25 |
| Estilos de texto | 11, mapeados a SwiftUI |
| Casos límite | 8 pantallas y 16 casos en tabla |
| Requisitos trazados a pantallas | 17 |
| Decisiones registradas con fecha y origen | ~45 |
| Handoff | PDF de 18 páginas |
Lo que puse en marcha
Más que aprender algo nuevo, este proyecto puso en marcha habilidades que ya tenía y las tradujo a otro ritmo: proyectos rápidos y demos para ImaageQ, con un proceso totalmente agentizado desde el descubrimiento y la definición hasta la entrega de la especificación para desarrollo. La velocidad la pusieron los agentes; el criterio siguió siendo humano.