Hola, soy Roiber Avendaño · Product Designer
Diseño productos y servicios digitales desde Córdoba, Argentina: UX/UI, design systems y accesibilidad, con IA para prototipar y construir. Vengo del Trabajo Social: diseño desde las personas, sus contextos y sus derechos.
Sitio accesible · WCAG 2.2 AA: leer la declaración de accesibilidadProyectos
Casos donde el diseño tuvo que convivir con restricciones reales: negocio, tecnología heredada y personas diversas.
El trámite más importante de la Oficina Virtual de EPEC, rediseñado de punta a punta: UI sobre un design system propio, lenguaje claro, accesibilidad y un prototipo construido con IA.
Ver caso: Rediseño del trámite para solicitar un nuevo servicio eléctricoGestión de plantillas de WhatsApp (HSM) dentro de un producto basado en Chatwoot: estados, reglas y errores claros para que el administrador no dependa de soporte.
Ver caso: Evoltis CX PlatformMi marca personal como design system: tokens claro y oscuro, ilustraciones y componentes en Figma, llevados a código con IA y con la accesibilidad como condición para publicar.
Ver caso: ro[i], diseñar el sistema, no las pantallasIdentidad visual y portfolio web para una Conversational AI Designer, construidos con el mismo método que ro[i]: sistema en Figma, IA sobre tokens y verificación de accesibilidad.
Ver caso: Portfolio de Ariana HernándezComunidad
Las interfaces son más accesibles cuando más personas adoptan la accesibilidad. Por eso también enseño, doy charlas y escribo.
Participé con dos charlas, disponibles en YouTube:
Expositor en el diálogo de saberes “Tecnoeducomunicación y procesos de innovación en Latinoamérica”, el 27 de octubre de 2026, transmitido en vivo por YouTube:
Artículo invitado en accesibilidad-web.info sobre accesibilidad y diseño UX.
Profesor de UX y Accesibilidad Digital. WCAG 2.2, normativa y metodologías de UX accesible. 2024 — actualidad.
Newsletter en LinkedIn para quienes empiezan: WCAG, foco, contraste y diseño inclusivo explicados de forma simple.
Suscribirte en LinkedIn (se abre en otra pestaña)
Sobre mí
Soy Product Designer con foco en UX/UI y accesibilidad digital. Vengo del Trabajo Social y la Administración Pública, y eso me hace mirar más allá de la interfaz: el contexto, las personas y las barreras que no siempre se ven.
Contacto
Escríbeme si quieres sumar a alguien que diseñe con criterio, sistema y accesibilidad. Respondo personalmente.
Product design de punta a punta: discovery, flujos, UI y design systems.
Una revisión de usabilidad y accesibilidad de lo que ya está en producción.
Charlas y talleres sobre accesibilidad, diseño inclusivo y diseño con IA.
Sobre mí · Roiber Avendaño
Diseño productos digitales de punta a punta: discovery, flujos, UI y design systems, con la accesibilidad como piso y la IA para prototipar y construir. Trabajo desde Córdoba, Argentina.
[01] Qué hago
Un perfil de producto completo: entiendo el problema, diseño la solución, la sostengo con un sistema y la verifico.
Discovery, investigación UX, user flows y arquitectura de información.
UI y design systems con tokens en dos capas, componentes y documentación.
Usabilidad y WCAG 2.2 desde el diseño, no como auditoría al final.
Prototipos navegables y vibe coding con IA, guiados por mis propias skills.
[02] Trayectoria
Cinco años diseñando productos digitales, de la interfaz al sistema que la sostiene.
[03] Formación
[04] Cómo trabajo
Combino el diseño de experiencias, el pensamiento sistémico y una mirada crítica sobre las barreras entre las personas y la tecnología. Por eso analizo contextos, cuestiono supuestos y busco qué hace que una experiencia sea realmente usable.
Lo que se diseña para quien más lo necesita termina sirviendo a todas.
Tokens, reglas y componentes antes que pantallas.
Contraste, teclado, foco y reflow se prueban antes de entregar.
[05] Mi diferencial
Mi formación en Trabajo Social y Administración Pública me permite conectar el diseño con las realidades sociales y con los servicios que forman parte de la vida cotidiana, sobre todo cuando hablamos de acceso, autonomía e inclusión.
Por eso me interesan los productos y servicios públicos: ahí una barrera de diseño puede dejar a alguien sin un derecho.
[06] Enseño y comparto
Investigo, enseño y comparto lo que aprendo, porque las interfaces son más accesibles cuando más personas adoptan la accesibilidad.
Profesor de UX y Accesibilidad Digital. 2024 — actualidad.
Dos charlas sobre accesibilidad en entornos educativos.
“Diseñar en los márgenes: accesibilidad y responsabilidad frente a la IA”. INNOTED, octubre de 2026.
Newsletter en LinkedIn para quienes empiezan.
Suscribirte en LinkedIn (se abre en otra pestaña)Hablemos
Si buscas a alguien que diseñe con criterio, sistema y accesibilidad, o quieres una charla para tu equipo, escríbeme. Respondo personalmente.
CV · Roiber Avendaño
Product Designer con más de cinco años en productos digitales para empresas y servicios públicos. Lidero procesos de punta a punta, de la investigación a la entrega, y gestiono design systems con WCAG 2.2 AA como piso. Construyo agentes y skills de IA con Claude para automatizar validaciones y medir usabilidad y accesibilidad, y uso la IA para llevar diseños de Figma a prototipos navegables. Vengo del Trabajo Social: diseño desde las personas, sus contextos y sus derechos.
[01] En resumen
Lidero el diseño de los productos digitales de EPEC, con impacto en más de 3.000 empleados y 1,5 millones de usuarios.
Diseñé desde cero el design system de EPEC: 313 componentes con WCAG 2.2 AA como piso.
Rediseñé el alta de servicio de la Oficina Virtual de EPEC: 7 barreras WCAG resueltas, Lighthouse de 72 a 96 y aprobación del cliente.
Ver caso: Rediseñé el alta de servicio de la Oficina Virtual de EPEC: 7 barreras WCAG resueltas, Lighthouse de 72 a 96 y aprobación del cliente.Diseñé la gestión de plantillas HSM de CX Platform y la llevé de Figma a un prototipo funcional con IA.
Ver caso: Diseñé la gestión de plantillas HSM de CX Platform y la llevé de Figma a un prototipo funcional con IA.Construí agentes y skills de IA con Claude que auditan el design system y miden usabilidad y accesibilidad.
[02] Trayectoria
[03] Formación
[04] Enseño y comparto
JADE 2026 · UNAM, México: dos charlas, «Cumplir sin incluir: por qué un entorno virtual accesible en el papel puede excluir en la práctica» y «Evaluación para el fomento de la accesibilidad en la educación».
Ver más (se abre en otra pestaña)Project Design Fest 9 · INNOTED, octubre de 2026: «Diseñar en los márgenes: accesibilidad y responsabilidad frente a la IA».
Artículo invitado «Más allá del usuario promedio: accesibilidad y diseño UX» en accesibilidad-web.info, 2025.
Ver más (se abre en otra pestaña)«Accesibilidad sin vueltas»: newsletter en LinkedIn sobre accesibilidad digital para quienes empiezan.
Ver más (se abre en otra pestaña)[05] Habilidades
Escribo
Artículos sobre producto, usabilidad, accesibilidad y design systems. Diseñar para todas las personas ya incluye la accesibilidad.
Cumplir las WCAG es necesario, pero no suficiente. Propongo pensar la accesibilidad como parte de la experiencia: no existe una persona usuaria promedio, y lo que se diseña para quien más lo necesita termina sirviendo a todas.
Entregas cortas para quienes empiezan: WCAG, foco, contraste y diseño inclusivo explicados simple.
Suscribirte en LinkedIn (se abre en otra pestaña)Pasé un trámite real por Lighthouse y WAVE. De 7 barreras detectaron 2, una a medias y no vieron 4: justamente las que traban el trámite.
Desde el rol de product designer: por qué diseñar para todas las personas no es una capa extra, sino la forma de hacer un producto usable.
Declaración de accesibilidad
Un portfolio sobre accesibilidad tiene que ser accesible. Este sitio cumple las pautas WCAG 2.2 nivel AA, que incluyen los 38 criterios de WCAG 2.0 que exige en Argentina la Disposición ONTI 6/2019, reglamentaria de la Ley 26.653. Está construido con el design system ro[i]: diseñado en Figma y llevado a código con Claude.
Todos los criterios de nivel A y AA de WCAG 2.2. Los que no aplican son los que piden algo que este sitio no tiene, como video o formularios.
| Criterio | Nivel | Estado | Cómo se cumple |
|---|---|---|---|
| 1.1.1 Contenido no textual | A | Cumple | Fotos con texto alternativo; ilustraciones y recreaciones de pantallas marcadas como decorativas, con su contenido dicho en texto. |
| 1.2.1 Solo audio y solo video (grabado) | A | No aplica | No hay audio ni video. |
| 1.2.2 Subtítulos (grabado) | A | No aplica | No hay video. |
| 1.2.3 Audiodescripción o alternativa | A | No aplica | No hay video. |
| 1.2.4 Subtítulos (en directo) | AA | No aplica | No hay contenido en directo. |
| 1.2.5 Audiodescripción (grabado) | AA | No aplica | No hay video. |
| 1.3.1 Información y relaciones | A | Cumple | Landmarks, un h1 por vista, títulos jerárquicos, listas y tablas con encabezados. |
| 1.3.2 Secuencia significativa | A | Cumple | El orden del código sigue el orden de lectura. |
| 1.3.3 Características sensoriales | A | Cumple | Ninguna instrucción depende de forma, posición o color. |
| 1.3.4 Orientación | AA | Cumple | Funciona en vertical y horizontal. |
| 1.3.5 Propósito de los campos | AA | No aplica | No hay formularios. |
| 1.4.1 Uso del color | A | Cumple | Estados y enlaces se distinguen también por texto, ícono, subrayado o flecha. |
| 1.4.2 Control del audio | A | No aplica | No hay audio. |
| 1.4.3 Contraste mínimo | AA | Cumple | Texto a 4,5:1 o más en claro y oscuro; el coral nunca va en texto chico. |
| 1.4.4 Cambio de tamaño del texto | AA | Cumple | Zoom al 200 % sin pérdida de contenido. |
| 1.4.5 Imágenes de texto | AA | Cumple | Solo logos, que están exceptuados. |
| 1.4.10 Reflow | AA | Cumple | Una columna a 320 px, sin scroll horizontal. |
| 1.4.11 Contraste no textual | AA | Cumple | Bordes de botones, foco e íconos con 3:1 o más. |
| 1.4.12 Espaciado del texto | AA | Cumple | Sin alturas fijas en el texto: soporta más interlineado y espaciado. |
| 1.4.13 Contenido al pasar el puntero o enfocar | AA | No aplica | No hay tooltips ni contenido que aparezca al pasar el puntero. |
| 2.1.1 Teclado | A | Cumple | Todo se usa con teclado, con elementos nativos. |
| 2.1.2 Sin trampas para el foco | A | Cumple | El foco entra y sale de todo. |
| 2.1.4 Atajos de una sola tecla | A | No aplica | No hay atajos de teclado. |
| 2.2.1 Tiempo ajustable | A | No aplica | No hay límites de tiempo. |
| 2.2.2 Pausar, detener, ocultar | A | Cumple | La animación del logo dura menos de 5 s, se saltea con cualquier tecla y no aparece si pediste reducir el movimiento. |
| 2.3.1 Tres destellos | A | Cumple | No hay destellos. |
| 2.4.1 Evitar bloques | A | Cumple | Enlace para saltar al contenido. |
| 2.4.2 Título de la página | A | Cumple | El título cambia con cada vista. |
| 2.4.3 Orden del foco | A | Cumple | Al cambiar de vista, el foco va al título principal. |
| 2.4.4 Propósito de los enlaces | A | Cumple | “Ver caso” suma el nombre del caso para lectores de pantalla; se avisa cuando un enlace abre otra pestaña. |
| 2.4.5 Múltiples vías | AA | Cumple | Menú principal, pie de página, enlaces desde el inicio y navegación entre casos. |
| 2.4.6 Encabezados y etiquetas | AA | Cumple | Títulos y botones describen su contenido o acción. |
| 2.4.7 Foco visible | AA | Cumple | Anillo de 2 px del design system en todo elemento interactivo. |
| 2.4.11 Foco no oculto | AA | Cumple | El header y el botón Volver arriba dejan margen de scroll para que el foco nunca quede tapado. |
| 2.5.1 Gestos del puntero | A | No aplica | No hay gestos multipunto ni de trazo. |
| 2.5.2 Cancelación del puntero | A | Cumple | Las acciones se activan al soltar, no al presionar. |
| 2.5.3 Etiqueta en el nombre | A | Cumple | El nombre accesible empieza o contiene el texto visible. |
| 2.5.4 Activación por movimiento | A | No aplica | Nada se activa moviendo el dispositivo. |
| 2.5.7 Movimientos de arrastre | AA | No aplica | No hay arrastre. |
| 2.5.8 Tamaño del objetivo (mínimo) | AA | Cumple | Botones y enlaces de 44 px; en el pie, 36 px como mínimo. |
| 3.1.1 Idioma de la página | A | Cumple | lang="es". |
| 3.1.2 Idioma de las partes | AA | Cumple | Las citas en inglés del caso de Ariana están marcadas con lang="en". |
| 3.2.1 Al recibir el foco | A | Cumple | El foco no provoca cambios de contexto. |
| 3.2.2 Al recibir entradas | A | Cumple | Ningún control cambia el contexto sin aviso. |
| 3.2.3 Navegación consistente | AA | Cumple | Header y pie iguales en todas las vistas. |
| 3.2.4 Identificación consistente | AA | Cumple | Mismos nombres para las mismas funciones. |
| 3.2.6 Ayuda consistente | A | Cumple | El email de contacto está siempre en el mismo lugar del pie. |
| 3.3.1 Identificación de errores | A | No aplica | No hay formularios. |
| 3.3.2 Etiquetas o instrucciones | A | No aplica | No hay formularios. |
| 3.3.3 Sugerencias ante errores | AA | No aplica | No hay formularios. |
| 3.3.4 Prevención de errores | AA | No aplica | No hay transacciones. |
| 3.3.7 Entrada redundante | A | No aplica | No hay formularios. |
| 3.3.8 Autenticación accesible (mínima) | AA | No aplica | No hay inicio de sesión. |
| 4.1.2 Nombre, función, valor | A | Cumple | Elementos nativos; el botón de tema y el menú exponen su nombre y estado. |
| 4.1.3 Mensajes de estado | AA | Cumple | “Copiar email” anuncia el resultado con role="status". |
Tokens Light/Dark y componentes en Figma. HTML, CSS y JavaScript sin frameworks, generados con Claude sobre esos tokens y revisados con mis skills de accesibilidad.
Escríbeme a roiberavendano@gmail.com y cuéntame dónde fue. Respondo y lo corrijo.
Caso de estudio · EPEC, Oficina Virtual
Rediseño de punta a punta del trámite más importante de la Oficina Virtual: análisis, UI sobre un design system propio, wording, accesibilidad y un prototipo navegable construido con IA y validado con el cliente.
Navegable de punta a punta: resumen, catálogo de trámites, solicitud en cinco pasos y seguimiento.
Paso de Documentación en la propuesta. Recreación sin datos reales.
[00] Resumen
Una lectura rápida del problema, mi aporte, la decisión clave y el estado actual del caso.
El trámite principal de la Oficina Virtual tenía barreras de accesibilidad, errores genéricos y un lenguaje técnico que complicaba el avance.
Diseñé un design system desde cero, rediseñé el flujo con criterio de accesibilidad, reescribí el wording y construí un prototipo navegable con IA.
Prioricé explicar cada documento y requisito técnico en lugar de quitarlos, porque son obligatorios por normativa y seguridad.
Aprobado por el cliente en septiembre de 2026 y en implementación.
[01] Contexto
Pedir un servicio nuevo es lo primero que hace cualquier persona que se muda o abre un comercio en Córdoba. Cinco pasos y documentación legal y técnica. Si el trámite tiene barreras, hay personas que directamente no pueden hacerlo solas.
Los selectores de Localidad y Barrio no tienen nombre: escucha “combobox” sin saber qué elegir.
“Consultar requisitos” y “Ver tutorial” no se alcanzan con Tab; al avanzar, el foco vuelve al inicio.
Los pasos pendientes están en gris claro (2,85:1) y el texto de ayuda es de 13 px.
Términos como “Informar destino” o “Monofásico 5KW” sin explicación, y errores que no dicen cómo corregirse.
[02] El problema en pantalla
Cómo respondía el trámite cuando algo fallaba, frente a los estados de la propuesta.
[03] Cómo lo abordé
Del sistema a la validación: cada etapa alimentó a la siguiente.
EPEC no tenía uno. Lo diseñé en Figma, lo validé con herramientas de accesibilidad y lo exporté a Claude.
Un agente recorrió el flujo real y extrajo el DOM. Yo verifiqué cada hallazgo y descarté falsos positivos.
Los cinco pasos rediseñados con componentes del sistema, con varias iteraciones sobre layout, jerarquía y estados.
Términos técnicos reemplazados por preguntas que cualquier persona entiende, con la voz del sistema.
Construido en Claude sobre el design system y mis skills de accesibilidad, UX writing y patrones.
Compartí el prototipo, el cliente dejó comentarios, ajusté y volví a publicar hasta la aprobación.
[04] Design system
EPEC no tenía un design system. Lo diseñé desde cero en Figma, con WCAG 2.2 AA como piso, y hoy vive exportado en Claude como librería de tokens y componentes. Todas las pantallas del trámite salen de ahí.
ev-color-bg-brand-bold#006D59ev-color-bg-brand-boldest#013524ep-color-text-brand#053F30ev-color-bg#FCFDFDev-color-border-focused#00564Aep-color-text-error#C01B1CRoboto · toda la UI de producto
Roboto Serif · solo display editorial
DM Sans · solo cards editoriales
Sistema completo diseñado desde cero: tokens en dos capas, tres familias tipográficas y 313 componentes.
Herramientas de accesibilidad corridas en Figma sobre todo el sistema.
Correcciones implementadas sobre el sistema ya construido.
Exportado como librería de código: tokens, Button (7 jerarquías), TextField, Card, Icon y Logo.
Usé del sistema: Button (primario, secundario y destructivo), TextField con estados de error y éxito, Card, Icon y tokens de color, tipografía y espaciado.
Y diseñé para este trámite los patrones que el sistema no tenía: stepper con estados, tarjetas de opción, avisos por tipo, fila de documento y contador de avance. Quedan listos para incorporarse a la librería.
[05] Decisiones de UI
Cada paso tiene la misma estructura, cada estado se ve y nada depende solo del color. Todo armado con componentes y tokens del sistema.
Completo y actual se distinguen por ícono y texto (“Paso 5 · 1 de 5 cargados”), no solo por color. En mobile pasa a una barra compacta.
Advertencia, éxito, información y error con fondo, borde e ícono propios. “Antes de subir” anticipa formatos y peso antes de que haya un error.
“1 de 5 obligatorios cargados”, barra de progreso y la lista de lo que falta. Queda fijo arriba mientras se sube.
Título, para qué sirve y estado. Cargado muestra nombre y peso, con acciones de ver y eliminar.
En lugar de radios chicos: área táctil grande, estado seleccionado con borde y fondo de marca.
Enviar es la única acción primaria. Cancelar va como destructiva secundaria, lejos del avance, y el “Paso 5 de 5” siempre a la vista.
[06] Wording y documentación
El formulario hablaba como el sistema. La propuesta habla como una persona que acompaña: qué se pide, para qué y dónde conseguirlo.
[07] IA en el proceso
La usé para analizar la interfaz actual y para construir el prototipo navegable sobre el design system.
Readapté y reconfiguré skills existentes para que la IA trabaje con mis criterios, no con los genéricos.
accesibilidad-inclusivaDiseñar pensando en perfiles reales antes de maquetar
wireframe-builderAcordar el layout antes de construir
uxwriting-referenceLa voz de EPEC: voseo, errores que orientan
patrones-referenceSnippets accesibles reutilizables
accesibilidad-reviewerQA técnico WCAG 2.2 AA
handoff-dev-generatorLa entrega a desarrollo
Y el ciclo se repite hasta la aprobación.
Menos iteraciones que en Figma, porque la validación es más directa: el cliente comenta sobre algo que ya funciona.
Límite: la IA no reemplaza la prueba con lector de pantalla ni con personas usuarias. Sirve para encontrar rápido y documentar bien; la validación sigue siendo humana.
[08] Accesibilidad
Hallazgos del flujo actual verificados en el DOM y la respuesta de la propuesta para cada uno.
Sin barreras críticas detectadas.
En todo el trámite2.1.1Requisitos y tutorial no se alcanzan con Tab2.4.3El foco vuelve al inicio al avanzar1.3.1Sin h1, pasos como h61.4.3Pasos pendientes a 2,85:1
| Criterio | Flujo actual | Propuesta |
|---|---|---|
| 2.1.1 Teclado | “Consultar requisitos” y “Ver tutorial” son enlaces sin destino: no se alcanzan con Tab. | Botones reales, alcanzables y con nombre claro. |
| 2.4.3 Orden del foco | Al avanzar de paso o cerrar el modal de error, el foco vuelve al inicio de la página. | El foco va al título del paso o al primer campo con error. |
| 4.1.2 Nombre, función, valor | Destino, Localidad y Barrio sin nombre accesible; el mapa es un iframe sin título. | Cada control con etiqueta asociada; mapa como vista previa con alternativa en texto. |
| 1.3.1 Información y relaciones | Sin h1; los pasos son h6; opciones de titularidad y medidor sin agrupar. | h1 único, pasos como lista con “paso actual”, grupos con fieldset y legend. |
| 3.3.1 · 3.3.3 Errores | Contrato inválido sin respuesta; errores de Domicilio en un modal genérico al final. | Validación por campo con mensaje que dice cómo corregir, vinculado al control. |
| 4.1.3 Mensajes de estado | Ninguna región aria-live: nada se anuncia al lector de pantalla. | Búsqueda de contrato, avance de carga y envío anunciados. |
| 1.4.3 Contraste | Pasos pendientes en gris #999 sobre blanco: 2,85:1. | Tokens del design system con contraste AA verificado. |
Pasé el flujo actual por Lighthouse y WAVE (72 · 69 · 71 y AIM 4,5). De las 7 barreras, detectaron 2, una a medias y no vieron 4: justamente las que traban el trámite. La propuesta llegó a 96 y AIM 10.
[09] Responsive
El alta se adapta sin perder contenido ni función. Además de comodidad, es un criterio de accesibilidad: 1.4.10 Reflow, el contenido se reorganiza en una columna sin scroll horizontal.
[10] Con el cliente
Mostrar cómo vive el trámite una persona con barreras. Dos decisiones que negocié:
El trámite sigue pidiendo cinco documentos obligatorios —incluida la selfie con DNI y el certificado de la Ley 10.281— porque son requisitos normativos y de seguridad que el diseño no puede eliminar.
Prioricé el trámite de mayor impacto en lugar de intervenir toda la Oficina Virtual de una vez, para construir una cultura de inclusión con un caso concreto y aprobado.
[11] Resultados
Diseño validado y aprobado por el cliente en septiembre de 2026, pendiente de despliegue. Los indicadores de uso se miden cuando esté en producción.
A medir en producción: consultas posteriores al trámite, solicitudes rechazadas por documentación y tiempo hasta el envío.
[12] Aprendizajes
Tres ideas que cambiaron cómo encaro la accesibilidad con un cliente.
Citar WCAG no movió la conversación. Mostrar quién quedaba afuera —alguien con lector de pantalla, una persona mayor haciendo el trámite sola— sí.
Me ahorró horas de diagnóstico. Pero cada hallazgo lo verifiqué yo, y cada solución salió del criterio y del design system.
Cambiar “Informar destino” por “Contanos para qué vas a usar la energía” saca una barrera sin agregar un solo componente.
Siguiente caso
Caso de estudio · Evoltis
Plantillas de WhatsApp que el administrador gestiona sin depender de soporte
Diseñé la gestión de plantillas HSM de CX Platform —listado, creación, edición y baja— dentro de una plataforma basada en Chatwoot, y llevé la propuesta de la media fidelidad en Figma a un prototipo en alta fidelidad construido con el sistema de Chatwoot.
El administrador dependía de soporte técnico para crear, editar y entender el estado de cada plantilla HSM.
Definí reglas por estado, errores con origen claro y un flujo de creación basado en patrones conocidos.
Usé el patrón de botones inline de Meta y variables con tipo para reducir rechazos sin inventar una UI nueva.
Se entregaron las tres historias de la épica, una matriz de acciones por estado y un prototipo funcional construido con el sistema de Chatwoot.
Listado, creación en cuatro pasos y acciones por estado, con el sistema de Chatwoot.
Prototipo en alta fidelidad: listado con el menú de acciones de una plantilla rechazada. Recreación sin datos reales.
[01] Contexto
CX Platform es la plataforma de atención omnicanal de Evoltis, construida sobre el código abierto de Chatwoot. La épica de plantillas HSM se dividió en tres historias: visualización (US 357), creación y edición (US 358), y deshabilitación y eliminación (US 359). La restricción: no rediseñar la base y respetar las reglas de Meta y los estados que devuelve Gupshup.
[02] Problema
Para tener una plantilla de WhatsApp, el administrador dependía de intervención técnica: no había un lugar en CX Platform para ver en qué estado estaba cada una, crearlas ni corregir las rechazadas. Y las historias llegaban con criterios de aceptación, pero sin estados, errores ni mensajes definidos.
[03] Proceso
Cada historia siguió el mismo protocolo, acordado con el PO y desarrollo sobre Jira y Confluence. Con la propuesta validada, sumé un segundo tramo con Claude para llevarla al código (sección 08).
[04] La propuesta
Un listado que muestra el estado de cada plantilla y un wizard para crearla. La media fidelidad alcanza: la estética la pone Chatwoot; lo que se valida es la estructura, los estados y el contenido.
El inbox seleccionado siempre visible, filtros y un badge por estado. El menú de cada plantilla muestra solo las acciones que ese estado permite.
Nombre e idioma primero: los datos que Meta no permite cambiar después se definen al comienzo del wizard.
Encabezado, cuerpo y pie con vista previa en vivo. Al escribir una llave aparece la variable completa en gris y Tab la completa, como las sugerencias de Gmail. Si no, se escribe a mano y, al cerrar las llaves, el sistema la agrega. El botón “Agregar variable” sigue disponible.
Agrupados por tipo, con contador de 10 y tipos que solo admiten uno. Cada tipo muestra únicamente los campos que necesita.
[05] Decisiones
Tres decisiones de la propuesta, cada una con su trade-off.
El administrador ya configura plantillas en Meta Business Manager. Adopté su patrón inline en lugar de un modal por botón y le sumé agrupación automática, tipos únicos y contador. Se resigna un diseño propio a cambio de cero aprendizaje.
Cada mensaje dice si la acción se completó y si el problema es de Gupshup o de CX Platform, para que el admin sepa a quién recurrir. Los textos son más largos, pero accionables.
Al escribir una llave, la variable completa aparece en gris y Tab la inserta: un patrón que ya se conoce de Gmail. Escribirla a mano o usar el botón también funciona. Se numeran solas y su tipo valida el ejemplo que pide Meta.
[06] Reglas
En una plataforma que no es propia, lo que más protege la experiencia son las reglas: qué acción está disponible en cada estado, cómo se comporta un campo y cuál es su límite. Las definí antes de diseñar, alineadas a las políticas de Meta y a los estados de Gupshup.
| Estado | Ver información | Editar | Deshabilitar / habilitar | Eliminar |
|---|---|---|---|---|
Aprobada · APPROVED | Sí | Sí (vuelve a revisión) | Deshabilitar | Sí |
Pendiente · PENDING | Sí | No | No | Sí |
En revisión · SUBMITTED | Sí | No | No | Sí |
Rechazada · REJECTED | Sí | Sí (reenvío) | No | Sí |
Deshabilitada · DEACTIVATED | Sí | No | Habilitar | Sí |
{{nombre_1}} para nombres, {{1}} para números; la numeración es automática y se reordena al borrar.[07] Wording
Los mensajes de Meta y Gupshup se tradujeron a qué pasó, por qué y qué hacer. Todos los errores siguen el mismo patrón: resultado de la acción + origen + detalle.
La ventana de 24 horas ha expirado.
La conversación con Juan Urquiza está bloqueada. Transcurrieron 24 horas sin actividad del contacto. Esperá su próximo mensaje para continuar.
Ocurrió un error al registrar el webhook de Gupshup. AppID incorrecto.
El canal no fue creado. Estamos teniendo inconvenientes con la conexión a Gupshup. Error: Authentication Failed.
Error genérico, sin origen ni resultado de la acción.
Los cambios no fueron guardados. Ocurrió un error inesperado en CX Platform. Intentá de nuevo o contactá a soporte si el problema persiste.
Tres advertencias con jerga de Meta: PENDING_DELETION, “Estructura no disponible”.
El nombre no podrá reutilizarse hasta que la eliminación se complete. Los mensajes pendientes seguirán enviándose durante 30 días.
APPROVED · PENDING · SUBMITTED · REJECTED · DEACTIVATED
Aprobada · Pendiente · En revisión · Rechazada · Deshabilitada, cada uno con ícono propio.
[08] Del Figma al código
Con la propuesta validada en media fidelidad, Claude toma el requerimiento, el flow aprobado y los tokens y patrones del repositorio de Chatwoot, y arma el prototipo en alta fidelidad. Lo que se valida con el PO y desarrollo ya se ve y se comporta como el producto.
Las escalas slate, blue, ruby, amber y teal de _next-colors.scss.
Variantes de Button.vue, Input.vue y DropdownMenu.vue replicadas en el prototipo.
Las reglas de las secciones 06 y 07: acciones por estado, variables, botones y mensajes.
Estructura, estados y contenido se acuerdan en media fidelidad, con ciclos cortos con PO y desarrollo. La alta fidelidad llega después, ya desde el código.
Las pantallas se arman con los tokens y patrones de Chatwoot: lo que se valida es lo que se construye. Se resigna explorar patrones fuera del sistema.
Variables, botones inline y acciones por estado se validan probándolos. Exige definir las reglas de uso antes de construir.
Los cuatro pasos de creación, edición, estados vacíos y las respuestas de éxito y error al guardar.
[09] Accesibilidad
Criterios aplicados en las decisiones de diseño: estados que no dependen solo del color (ícono + texto en badges y banners), errores identificados por campo con indicación de cómo corregirlos y lenguaje sin tecnicismos, por ejemplo, reemplazar “ventana de 24 horas” por qué pasó y qué hacer.
[10] Resultados
Con este proceso se diseñaron y entregaron las tres historias de la épica de plantillas HSM, y la propuesta se llevó a un prototipo en alta fidelidad construido con el sistema de Chatwoot.
[11] Aprendizajes
En un producto que no es propio, el valor del diseño está en definir reglas y estados antes que pantallas. Llevar la propuesta al código con el sistema de Chatwoot acortó la distancia entre lo que se valida y lo que se construye, pero no reemplaza el acuerdo con el PO ni la revisión de factibilidad con desarrollo.
Siguiente caso
Rehice mi marca ro[i] como un design system con tokens claro y oscuro, un sistema de ilustración y componentes. Lo documenté para que una IA pudiera leerlo y construí este sitio sobre él. La accesibilidad no fue una revisión final: fue la condición para publicar.
Un portfolio en Framer, con tipografías genéricas, sin modo oscuro y sin forma de demostrar la accesibilidad que enseño.
Definí el sistema, sus reglas y el método para que la IA construya sobre tokens y no sobre gustos.
Tratar el código generado como una propuesta: no se publica hasta pasar axe, teclado y reflow.
Este sitio, con 0 violaciones de axe en claro y oscuro, y un sistema que también alimenta las piezas de LinkedIn.
[00] La marca
Una marca personal que dice cómo trabajo: el sistema existe para que cada persona entre.
Las primeras letras de Roiber, en minúscula y sin adornos.
El punto es la cabeza y el trazo, el cuerpo. Es la única pieza en coral porque es lo que importa.
En código, los corchetes agrupan y ordenan. Aquí rodean a la persona: el sistema se arma alrededor de ella, no al revés.
Diseñar para todas las personas: no existe la persona promedio, y lo que sirve a quien más lo necesita termina sirviendo a todas.
[01] Alcance
Un sistema chico pero completo, pensado para tres salidas: el portfolio, las piezas de LinkedIn y un newsletter.
[02] Problema
El sitio anterior estaba en Framer, hecho con una plantilla en modo oscuro: se veía correcto, pero usaba tipografías de catálogo y no había forma de verificar su accesibilidad. Para alguien que se posiciona en accesibilidad, eso es un problema de credibilidad.
Ver el portfolio anterior, con casos más antiguos (se abre en otra pestaña)
Cada pieza nueva se diseñaba desde cero. LinkedIn, el portfolio y las presentaciones no se parecían entre sí.
No podía mostrar contraste, foco ni reflow verificados. Solo podía afirmarlos.
Degradés, tarjetas con sombra y un acento en todos lados. Quería sacar todo lo que se viera genérico.
[03] Metodología
La IA construye rápido, pero sin restricciones decide por ti. Lo que cambié fue el orden: primero el sistema y sus reglas, después la conversación con la IA, y al final una verificación que no se negocia.
Tokens y componentes creados con el agente de IA de Figma, revisados uno por uno.
Contraste de cada par texto–fondo en claro y oscuro, antes de diseñar pantallas.
El sistema exportado a un documento que la IA lee como contrato: valores reales, sin inventar.
Claude construye sobre los tokens. axe, teclado y reflow deciden si se publica.
Uso un plugin, adaptado de una skill comunitaria, que extrae el design system desde Figma y genera el design.md. Tiene tres reglas: nunca inventar valores, conservar los nombres originales de los tokens y resolver cada token semántico hasta su hex final.
Por qué un documento y no capturas. Una captura le muestra a la IA cómo se ve algo. El documento le dice qué valor usar y por qué, y eso se puede revisar.
Las skills como barandas. Uso mis skills de accesibilidad inclusiva y de revisión técnica para que cada pedido arranque con WCAG 2.2 AA como piso.
El gate. Si algo no pasa la verificación, no se publica. La IA propone; la verificación decide.
[04] Tokens
Tres capas: primitives con los valores, semánticos con el rol y tokens de componente con el uso. Los componentes nunca usan primitives, por eso cambiar de modo es cambiar a qué primitive apunta cada rol, sin tocar el componente.
La misma tarjeta con los tokens de cada modo, independientemente del tema que tengas activo.
La primera versión oscura era un navy profundo y se sentía pesada. Creé la rampa ink (950 a 600) y realiasé 22 semánticos del modo oscuro a esa rampa. El modo claro no cambió.
En oscuro, el coral de texto pasa a #FF8178 para mantener el contraste. El texto chico nunca va en coral, en ningún modo.
Atkinson Hyperlegible Next en 600 para títulos y su versión Mono para eyebrows, tags y numeración. Reemplazó a Space Grotesk e Inter.
Tres capas, y cada nombre dice en qué capa está. La regla es simple: un componente nunca toca un valor directo. Pide un rol, y el rol sabe qué valor usar en cada modo.
brand/navy/900Dice qué valor es. Familia y tono, sin intención de uso.
familia / tonoaction/primaryDice para qué sirve. Es la única capa que cambia entre Light y Dark.
categoría / rol-estadobutton/primary/backgroundDice dónde se usa. Siempre apunta a un semántico.
componente / variante / propiedadbutton/primary/background → action/primary → brand/navy/900 #09142F Light
button/primary/background → action/primary → brand/navy/50 #F0F3F9 Dark
| Semántico | Para qué | Light | Dark |
|---|---|---|---|
surface/default | Fondo de la página | brand/navy/25 #F7F8FB | ink/950 #0D1017 |
text/primary | Títulos y texto principal | brand/navy/900 #09142F | brand/cream/100 #FBF9F7 |
action/primary | Botón principal | brand/navy/900 #09142F | brand/navy/50 #F0F3F9 |
text/link | Enlaces | blue/600 #1D4ED8 | blue/300 #93C5FD |
text/accent | Acento coral en texto grande | brand/coral/700 #C43832 | brand/coral/400 #FF8178 |
focus/ring | Anillo de foco | blue/600 #1D4ED8 | blue/300 #93C5FD |
graphic/support | Trazos de apoyo en ilustraciones | brand/navy/300 #90A2CB | brand/navy/600 #253A6A |
Variantes por jerarquía y por estado, nombradas por grupo: Grupo / Componente.
[05] Ilustraciones
Doce ilustraciones lineales hechas con las mismas piezas: círculos, trazos y un punto. Están armadas con los tokens gráficos del sistema, así que cambian solas con el modo. Prueba el botón de modo oscuro.
El coral se reserva para el punto: representa a la persona, igual que el punto de la i del logo.
La estructura lleva el trazo más grueso; el apoyo y el apoyo sutil, trazos más finos y tonos más claros.
graphic/structure, graphic/support, graphic/support-subtle y el coral de acento. En oscuro cambian de primitive sin redibujar nada.
Los corchetes son del logo. Junto a él, en las ilustraciones recargaban las piezas.
Las mismas ilustraciones arman las portadas de este portfolio y los destacados de LinkedIn, con una plantilla de Figma con propiedades de texto.
[06] Interacción
Cada componente tiene sus estados definidos como variantes en Figma y como tokens en código. El foco usa el anillo del sistema: 2 px, separado 2 px del elemento y con contraste suficiente en claro y en oscuro.
Pruébalo. Recorre esta página con Tab: cada enlace y cada botón muestra el mismo anillo, y el header nunca lo tapa.
[07] Movimiento
Exploré varias animaciones para la entrada. Elegí el Rebote porque cuenta la marca en dos segundos: la persona llega, el sistema se abre para recibirla y se acomoda alrededor de ella.
[08] Accesibilidad transversal
Cada decisión tuvo una prueba asociada. Lo que no pude probar todavía está marcado como pendiente.
[09] Evolución
| Decisión | Antes | Ahora | Por qué |
|---|---|---|---|
| Plataforma | Framer | HTML propio sobre tokens | Control total del código y de la accesibilidad. |
| Tipografía | Space Grotesk e Inter | Atkinson Hyperlegible Next y Mono | Legibilidad, y su i se parece a la del logo. |
| Títulos | Prueba con serif | Sans en 600 | Descarté la serif por legibilidad. |
| Color | Fondo crema y mucho coral | Neutros fríos y un punto coral por vista | Más sobrio; el coral recupera su función de señal. |
| Modo oscuro | Navy profundo | Rampa ink neutra | Menos peso visual y mejor lectura prolongada. |
| Ilustraciones | Con corchetes | Lineales, sin corchetes | Junto al logo recargaban las piezas. |
[10] Resultados
[11] Aprendizajes
Con IA, el trabajo de diseño se mueve hacia arriba: menos pantallas y más reglas, documentación y criterio de verificación. El sistema bien escrito es lo que evita que el resultado se vea “hecho con IA”. Y la accesibilidad sale más barata cuando es una condición para publicar que cuando es una auditoría al final.
Siguiente caso
Diseñé la identidad visual y el portfolio web de Ariana Hernández, Conversational AI Designer. Seguí el mismo método que en mi marca ro[i]: primero el sistema en Figma, después la IA construyendo sobre esos tokens y, al final, una verificación de accesibilidad que decide si se entrega.
Inicio, trabajos, sobre mí, contacto y dos casos de estudio. El sitio está en inglés.
Página de inicio, recreada a partir del prototipo entregado.
[01] El encargo
Ariana diseña experiencias conversacionales y de IA. Su recorrido pasó por la Literatura, la docencia y la escritura antes de llegar al diseño conversacional, y su portfolio tenía que contar eso.
Conversational AI Designer: diseña cómo las personas se comunican con la tecnología, del lenguaje a la arquitectura de un agente.
Dos casos complejos: un asistente de RR. HH. con IA para varios países de Latinoamérica y una plataforma de aprendizaje convertida en agente conversacional.
Editorial, cálido y humano. Una identidad propia, sin nada en común con la mía.
[02] Identidad
Partí de un design system y un tablero de inspiración en Figma. La identidad combina una serif expresiva para los títulos con formas que recuerdan una conversación: burbujas, puntos de escritura y semicírculos.
Tipografía
Conversations that count.
Fraunces Black · títulos
CONVERSATION DESIGN · AI AGENTS
Space Grotesk · etiquetas e interfaz
I design conversational and AI experiences.
Inter · texto
El rosa y el naranja son los colores más vivos de la marca, pero no llegan al contraste que pide el texto. Por eso el rosa tiene dos tokens y el naranja queda solo para gráficos.
--action#0B7268--accent#0A6E63--connection#F3269B--connection-text#C21A7C--support#E07D10--surface#FAFAF7Contrastes calculados contra el fondo claro #FAFAF7, salvo la acción, que va con texto blanco.
[03] Método
El procedimiento es el de ro[i]. Lo que cambia es el contrato que recibe la IA: construye con los tokens de Ariana, no con los míos.
Design system y tablero de inspiración antes de cualquier pantalla.
Color, tipografía y espaciado, en claro y oscuro, con sus nombres originales.
Claude arma las seis vistas sobre esos tokens, sin inventar valores.
Contraste AA, objetivos de 44 px, foco visible y movimiento reducido antes de entregar.
[04] Accesibilidad
Una identidad con mucho color y una serif de display también puede cumplir WCAG 2.2 AA. La clave fue decidir dónde va cada cosa.
[05] Entrega
Un prototipo navegable listo para publicar, con modo claro y oscuro.
Presentación, trabajos seleccionados, qué hace y cómo piensa, con una frase propia: “Conversations that count”.
Un listado y dos casos de estudio largos, con contexto, decisiones de diseño y resultados.
Su recorrido de la Literatura a la IA, y un contacto que imita una conversación de chat.
[06] Aprendizajes
El resultado no se parece en nada a ro[i]: otra tipografía, otra paleta, otro tono. El método no impone una estética; ordena cómo se toman las decisiones.
Con los tokens documentados, la IA no completa los huecos con su gusto ni con el mío. Construye con la marca de Ariana.
Siguiente caso