IA y automatización5 min de lectura

Qué puede aportar la IA a un proceso de diseño

Dónde puede ayudar la IA y dónde hace falta criterio, evidencia y revisión: contenido, prototipos, privacidad y decisiones de producto.

Actualizado el

Collage de una fachada con una alternativa superpuesta y anotaciones de revisión.

La IA puede ayudar a organizar información, explorar alternativas y resolver partes repetitivas de un proceso de diseño. No reemplaza la evidencia necesaria para entender un problema ni la responsabilidad de decidir. La pregunta útil no es si conviene usarla en todo, sino qué tarea concreta puede asistir, con qué información y bajo qué revisión.

Una salida convincente puede estar equivocada o ignorar condiciones que el sistema no conoce. Por eso conviene definir antes el material de entrada, el criterio de aceptación y quién revisa el resultado. Si esas condiciones son vagas, automatizar la tarea puede multiplicar dudas en lugar de resolverlas.

Ordenar información sin convertirla en evidencia

Un conjunto de notas puede organizarse por temas, preguntas y decisiones pendientes. La IA puede proponer una clasificación o resumir un documento extenso. Esa organización sirve para trabajar con el material, pero no transforma las notas en hallazgos validados. Tampoco permite afirmar que una opinión aislada representa a un público completo.

Es importante conservar la referencia al original. Un resumen que elimina contradicciones puede hacer parecer que existe un acuerdo donde no lo hay. Antes de usarlo como insumo, revisá ejemplos concretos, excepciones y fragmentos omitidos. Si un dato no aparece en la fuente, no corresponde completarlo porque “suena probable”.

Explorar textos y alternativas

Para una interfaz se pueden probar maneras de nombrar una acción, explicar un error o presentar un servicio. La utilidad está en comparar opciones contra un contexto, no en elegir la versión más vistosa. Un mensaje de error debe ayudar a corregir una situación; una bajada debe representar un alcance real.

La revisión tiene que incluir veracidad y tono. No se pueden inventar testimonios, investigaciones ni capacidades de un negocio para completar un layout. También conviene leer la alternativa dentro de la pantalla: una frase breve puede ser ambigua, y una explicación correcta puede necesitar un lugar distinto para no competir con la acción principal.

Prototipos para preguntas delimitadas

Un prototipo generado o asistido puede ayudar a explorar una interacción, representar un estado o discutir un flujo. Eso no lo convierte en producto terminado. Hay que distinguir lo que simula de lo que realmente implementa, especialmente si involucra envío de datos, pagos, permisos o información sensible.

Antes de probarlo, definí la pregunta. “¿Se entiende cómo volver a los resultados?” es distinta de “¿Este producto resuelve la necesidad?”. El primer prototipo puede ayudar con una parte del recorrido; no alcanza para responder la segunda. También necesita contenidos representativos y estados de error, no solo el camino que funciona.

Tareas repetitivas y revisión

Hay tareas con criterios relativamente claros: revisar consistencia de nombres, detectar enlaces sin destino, identificar variaciones de un componente o preparar un primer borrador de documentación. La IA puede asistir, pero la regla de aceptación debe existir. Sin ella, la persona revisora termina evaluando cada salida desde cero.

  • Definí qué parte de la tarea es repetitiva y cuál requiere decisión.
  • Usá un ejemplo correcto y otro que no debería aceptarse.
  • Pedí que las dudas queden visibles, sin completar datos ausentes.
  • Revisá una muestra representativa y los casos de mayor riesgo.
  • Conservá una forma de corregir o descartar el resultado.

Lo que no conviene delegar como si estuviera resuelto

Decisiones de producto e investigación

Priorizar una función exige entender objetivos, restricciones y consecuencias. Un modelo puede enumerar alternativas, pero no conoce automáticamente la operación. Generar personas ficticias o respuestas a entrevistas no sustituye conversar con usuarios. Si usás escenarios inventados, deben quedar identificados como hipótesis y no como evidencia del proyecto.

Accesibilidad y privacidad

Una revisión automática puede señalar posibles problemas de contraste o estructura, pero no demuestra que un recorrido sea accesible. Hace falta revisar el uso con teclado, tecnologías de asistencia y estados reales. Del mismo modo, antes de compartir documentos con una herramienta hay que comprobar permisos, información sensible y políticas aplicables; no asumir que cualquier material se puede cargar.

Ejemplo hipotético: mensajes de un formulario

Un equipo necesita revisar los mensajes de un formulario de consulta. Puede darle a la herramienta una descripción sin datos personales: campos, condiciones y errores previstos. Le pide alternativas para un archivo no admitido, un campo obligatorio y un envío fallido. Después compara si cada mensaje explica el problema y una acción posible.

La revisión detecta que una alternativa dice “Intentá más tarde” para todos los errores. Ese texto no ayuda a corregir un formato incorrecto. El equipo descarta la variante y mantiene mensajes diferentes por condición. Antes de incorporarlos, los revisa dentro de la interfaz y comprueba que no se borre lo escrito cuando falla el envío. El ejemplo muestra un criterio de revisión, no un resultado medido.

Un flujo de trabajo con control

Conviene empezar por una tarea pequeña, con información autorizada y una forma sencilla de revisar el resultado. Registrá qué se pidió, qué se aceptó y qué necesita revisión adicional. Ese registro ayuda a repetir una tarea con criterio, sin presentar la salida de la herramienta como una decisión tomada por una persona o por usuarios.

Si el proceso exige evaluar cada caso sin reglas claras, quizá todavía no es una buena tarea para automatizar. Separá exploración de publicación: generar alternativas no debería enviar mensajes ni modificar contenido público por sí solo. La supervisión tiene que ocurrir antes de la acción que puede afectar a otras personas.

Para empezar, elegí una tarea que no implique decisiones irreversibles y definí cómo reconocer una salida incorrecta. El brief inicial sigue siendo necesario, y automatizar tareas del sitio requiere controles específicos. Si necesitás ordenar ese proceso, podemos evaluar usos de IA y automatización dentro de un alcance explícito, sin sustituir validación con usuarios.

Ver el blog
  1. Composición de un brief, mapa del sitio y wireframes junto a una propuesta web de restaurante.
    UX/UI5 min de lectura

    Diseñar una web no empieza en Figma

    Definí objetivos, tareas, contenido y mantenimiento antes de dibujar pantallas. Incluye preguntas para armar un brief útil.

  2. Máquina ilustrada que procesa sobres y los distribuye en tres bandejas.
    IA y automatización5 min de lectura

    Qué tareas conviene automatizar en un sitio web

    Evaluá reglas, errores y supervisión antes de automatizar consultas, avisos o reportes. Incluye un recorrido sencillo y criterios de mantenimiento.

  3. Composición de flujos, wireframes móviles, componentes y referencias de una interfaz.
    UX/UI5 min de lectura

    Qué incluye un proyecto UX/UI más allá de las pantallas

    Problema, flujos, componentes y estados: entregables y criterios para revisar una propuesta UX/UI sin dar por hecha su validación.