El componente que define cómo se presenta, atribuye y acciona el contenido generado por IA en Oracle. Lo que comenzó como una respuesta a la presión de integrar IA se convirtió en un estándar de plataforma con alcance en más de 12 page templates.
Los equipos de producto de Oracle estaban construyendo experiencias de AI summarization de forma independiente. No había un estándar. No había un componente compartido. No había un camino de adopción. Conforme la demanda se aceleró, la fragmentación se volvió insostenible.
Un audit cross-producto hizo visible la situación desde tres dimensiones: el usuario, el producto y la tecnología.
El audit reveló tres dimensiones: los usuarios enterprise recibían output inconsistente e inverificable; los equipos de producto resolvían el mismo problema desde cero; la tecnología (Ask Oracle) requería un componente diseñado para escala desde el inicio.
Antes de cualquier exploración de diseño, impulsé claridad sobre una pregunta fundamental: ¿qué hace exactamente este componente? La respuesta se convirtió en el filtro de todas las decisiones que vinieron después.
Cada elemento que consideramos agregar, cada interacción que evaluamos, tenía que pasar por la definición. No por preferencia estética, no por convención de otros sistemas — por la función que el componente debía cumplir.
Esta frase se convirtió en un filtro. Y al final del proyecto, cuando los stakeholders incorporaron nuevos requerimientos, la revisamos y extendimos: el Summary también provee acciones contextuales que permiten al usuario extender capacidades y tomar acción basada en la información presentada.
A partir de la definición surgieron tres principios — cada uno vinculado a una decisión de implementación concreta.
El summary debe surfacear la información más relevante para la decisión actual del usuario. En la práctica: colaboré con desarrollo para asegurar que la arquitectura del prompt de IA priorizara insights clave, no resúmenes genéricos.
Los usuarios necesitan entender de dónde viene la información. En la práctica: la atribución de fuentes no era opcional — se convirtió en un elemento obligatorio de la anatomía desde el inicio del diseño.
El summary debe ser legible de un vistazo. En la práctica: establecimos una guía de voz para evitar patrones de lenguaje generado por máquina — el contenido debía leerse como un insight humano, no como un volcado de datos.
Nada se agregó por defecto. Cada elemento del componente tuvo que justificar su presencia frente a los principios de diseño. Si no superaba ese filtro, quedaba fuera.
Un marcador visual que señala contenido generado por IA. Ya establecido como patrón en Redwood, le da a los usuarios una señal de reconocimiento inmediata y consistente en todos los productos de Oracle — antes de leer una sola palabra.
Un título generado por IA que resume el insight más crítico de la página. No es una etiqueta. No es una categoría. Es un enunciado específico y accionable derivado de los datos.
La narrativa central — concisa, escaneable, escrita para apoyar la toma de decisiones. Aquí es donde el componente genera valor real. Establecimos guías para mantenerlo compacto y legible, reconociendo al mismo tiempo una restricción real: no controlamos completamente lo que produce la IA.
Referencias vinculadas a las fuentes de datos usadas para generar el summary. Es lo que separa un componente de IA confiable de una caja negra — los usuarios pueden verificar, profundizar o cuestionar lo que están leyendo.
La longitud del contenido generado por IA está frecuentemente fuera de nuestro control. El diseño contempla los edge cases donde el summary se extiende: un patrón de truncamiento con trigger "More" para que el componente degrade con elegancia sin romper el layout.
Los summaries podían tardar tiempo considerable en renderizarse dependiendo del volumen de datos. Coordiné con Motion para definir un estado skeleton con la etiqueta "Generating content" — comunica proceso sin generar layout shift ni confusión.
Tab mueve foco al primer elemento interactivo. El componente usa role="region" con aria-label="summary". El headline está marcado como heading level 2. El grupo de CTAs usa role="group" con aria-label="summary actions".
A mitad del proyecto, las revisiones nos pusieron en contacto con equipos adicionales que querían adoptar el Summary para contextos que no habíamos diseñado originalmente. Dos requerimientos surgieron.
Nos dimos cuenta que no teníamos control sobre la longitu que el AI Summary podía tener. Habiamos diseñado guías y recomendaciones para que el AI Summary funcionara como un verdadero resumen; sin embargo, no había una forma de evitar casos de longitudes extensas. Por ello, exploramos como deberiamos de actuar en esas circuntancias
Cuando el AI summary funciona en dashboards o reportes complejos era necesario darle mayor prominencia al heading. Después de algunas conversaciones concluimos que era necesario diseñar una opción donde el heading era más prominente; al mismo tiempo pensamos que lo ideal sería manejar diferentes escalas basándonos en brakpoints para hacer un uso más eficiente del espacio
La presión de los stakeholders no fue un obstáculo — fue un acelerador de diseño. Mostrar que sus necesidades estaban mapeadas a un roadmap los dispuso a aceptar una v1 sin todo lo que necesitaban. El espíritu de versionamiento se convirtió en una herramienta de negociación.
"Diseñar un componente de design system es fundamentalmente
diferente a diseñar una feature de producto. La superficie que
estás diseñando no es la UI — es el comportamiento de adopción
de otros equipos."
El componente Summary se lanzó en Dashboard y Data Authoring — los contextos de mayor densidad de datos en Oracle y los adoptadores más naturales como punto de inicio.
Los equipos de producto obtienen comportamiento consistente de AI summarization sin tener que diseñarlo, construirlo ni mantenerlo. El design system se convierte en el mecanismo de distribución — SCM, ERP y Finance heredan el componente a través de los page templates.
La cadencia de revisiones con stakeholders solía estirarse hasta dos semanas entre cada contacto. Habría empujado prototipos de forma más temprana y frecuente — sin esperar a las revisiones calendarizadas. La restricción de una junta programada no debería ser el cuello de botella de una decisión de diseño.
Cuando equipos adicionales llegaron con nuevos requerimientos a mitad del proyecto, mi instinto fue gestionar el alcance. Lo que funcionó fue un encuadre diferente: mostrar que sus necesidades estaban mapeadas a un roadmap. Una vez que podían ver eso, estaban dispuestos a aceptar una v1 sin todo lo que necesitaban.
El data bloom funciona como identificador cuando hay un solo summary en la página. Pero conforme otros componentes — como los Comparison Cards — comienzan a embeber sus propios summaries generados por IA, el data bloom pierde su distintividad. Múltiples blooms en una sola página generan ruido visual y diluyen la señal que debían proveer.
¿Cómo comunicas "este contenido fue generado por IA" de una forma que escale con gracia desde un summary prominente a nivel de página hasta múltiples instancias embebidas? ¿Existe un patrón más ligero que funcione en ambas escalas? Esa pregunta no tenía respuesta dentro del alcance de este proyecto. Es la pregunta correcta para el siguiente.