Tres formas de crear un Job: diseñar asistencia con IA en un marketplace de staffing
Lo que aprendí diseñando tres rutas de entrada en paralelo en Wolf —voz, lenguaje natural y archivos Excel—. Decisiones de UX, las trampas con las que choqué, y por qué la IA no reemplaza al diseño.
El día que un cliente nos pidió crear 47 Jobs en una sola sesión, supe que el formulario tenía que morir.
No el formulario como concepto — sino el formulario como única forma de entrada al sistema. Cuando una operadora de una staffing company en Texas tiene que crear 47 turnos cada lunes a las 7 AM para cubrir las próximas dos semanas, y cada turno tiene su horario, su tipo de trabajo, sus skills requeridos y su pay rate, el formulario tradicional no es una experiencia. Es un castigo.
Esta es la historia de cómo terminamos con tres formas distintas de crear un Job en Wolf —dictado por voz, texto en lenguaje natural y carga de Excel— y por qué creo que diseñar para esa flexibilidad de entrada es una de las habilidades más subestimadas del Product Design en 2026.
Contexto: cuando el formulario gana, los operadores pierden
Wolf es un marketplace multi-lado para la industria de staffing en Estados Unidos. Tres tipos de usuarios coexisten: Admins de la staffing company, Clients (empresas que contratan staff), y Job Seekers (workers que reciben los Jobs en su app mobile).
5K–20K
Usuarios activos
100+
Staffing companies
20–80
Jobs por operadora / semana
Cuando llegué al producto, el flow era el formulario clásico. 47 Jobs × 14 campos = 658 inputs. A 2 segundos por input — siendo optimistas — son 22 minutos de data entry para algo que conceptualmente la operadora ya tenía en su cabeza desde el martes anterior.
El formulario no era el problema. El problema era que fuera la única puerta de entrada al sistema.
La hipótesis: cómo se entra un dato no es cómo se guarda
La primera decisión de UX que tomé fue separar dos cosas que el equipo de producto venía confundiendo: cómo el usuario expresa intención vs cómo el sistema representa esa intención internamente.
Un Job, dentro del sistema, siempre va a ser el mismo objeto: un Job con un schedule, uno o más JobType, un set de requirements y un payRate. Esa estructura no cambia. Lo que sí podía cambiar era cómo la operadora llegaba a ese objeto.
- Voz. Para la operadora que está manejando o multi-tasking. "Necesito 4 cocineros para el sábado de 8 AM a 4 PM en el cliente Hilton Austin, pay rate 22." El sistema escucha, transcribe, parsea y muestra el Job estructurado para confirmación.
- Lenguaje natural escrito. Para la operadora que prefiere tipear pero no quiere navegar 14 inputs. Misma idea, distinto canal.
- Excel upload. Para la operadora que ya tiene la información en un spreadsheet (lo que pasa el 70% del tiempo). Drag, drop, mapeo automático de columnas, preview, confirmación.
El formulario quedó como cuarta opción — para cuando el operador quiere control granular o está creando un Job que no encaja en ningún patrón previo.
Decisión #1 — Convergencia visual antes de enviar
Acá viene una sutileza que cambió el producto: las tres rutas convergen en la misma pantalla de preview antes de hacer submit. Esto sonó obvio cuando lo escribí en el doc de discovery, pero la primera versión de los engineers fue tener tres flujos completamente separados, sin punto de convergencia.
Si el operador no ve el mismo objeto Job en la misma pantalla antes de submit, no va a confiar en la IA. Y si no confía en la IA, va a volver al formulario.
La pantalla de preview se convirtió en el contrato. Lo que el operador ve es exactamente lo que se va a crear en el sistema. Cualquier dato que la IA infirió tiene un badge sutil que dice "inferred". Click en el badge → muestra de dónde salió esa inferencia. Edit inline en cualquier campo antes de submit.
La entrada podía ser flexible; la verificación, no. Esa asimetría fue lo que nos permitió llevar la IA a producción sin perder la confianza del operador.
Decisión #2 — Manejar el desastre del Excel real
La parte de voz y NLP fue divertida de diseñar. La parte de Excel fue donde sufrí. Excel real, en producción, en staffing, es un desastre estructural:
- Columnas con nombres distintos según quién armó el archivo (pay, payrate, pay_rate, $/hr).
- Schedules expresados como rango, como días concretos, o como párrafo prosa.
- Múltiples JobTypes embedded en una sola fila usando comas, slashes o columnas según el cliente.
- Filas vacías mezcladas. Headers en la fila 3 en vez de la 1. Hojas con notas que nadie leyó.
La trampa común es diseñar el "happy path" y mostrar un error genérico cuando algo sale mal. El error genérico es donde mueren los productos operacionales.
Lo que hicimos
- Parser tolerante. El backend intenta varias estrategias de mapeo. Cada una produce una confianza.
- UI de reconciliación. Si la confianza es alta, autoaplica el mapping con una banner sutil para revisar. Si la confianza es baja, abre un step explícito donde el operador arrastra columnas a campos.
- Preview row-by-row. Antes de submit, el operador ve cada fila como un Job individual. Los Jobs con warnings se marcan en naranja y se editan inline.
- Partial submit. Si 45 de 47 Jobs están OK y 2 tienen warnings, el operador puede submitear los 45 y dejar los 2 en draft.
Partial submit fue la que más resistencia generó en engineering. La razón era razonable: cómo manejar el estado de "draft Jobs pendientes" en la base de datos. Pero desde UX la respuesta era obvia: si los obligamos a resolver el Excel completo antes de crear un solo Job, el operador prefiere abrir el formulario y empezar de cero. Lo vi en testing 6 veces.
Acordamos un compromiso: drafts persisten 7 días, se notifica al operador 48 horas antes del cleanup. Resolvió el problema de UX sin generar un graveyard infinito en la DB.
Decisión #3 — Cuándo NO usar IA
Después del segundo mes en producción, descubrimos algo incómodo: para Jobs muy simples — un solo turno, un solo worker, un cliente conocido — la ruta de voz/NLP era más lenta que el formulario.
Tenía sentido en retrospectiva: la IA tiene un overhead conversacional. Decir "necesito un electricista para mañana de 9 a 5 en Marriott downtown" toma 5 segundos. Pero llenar tres campos en un formulario optimizado toma 4. Y el preview de la IA agrega otros 3-4 segundos para confirmar.
La IA no es la experiencia del producto. Es apenas una de las formas de entrar a ella.
Esta distinción me parece la más subestimada del momento. Hay muchos productos diseñando con la premisa de que IA = todo conversacional = mejor. Es falso, y el dato lo demuestra.
Lo que llevo a mi próximo rol
- Separar intención de representación. El sistema interno puede ser rígido. La forma en que el usuario llega a él no tiene por qué serlo.
- La pantalla de convergencia es el contrato. Cualquier flow paralelo necesita un único punto donde el usuario verifica antes de comprometer.
- Diseñar el camino del error con el mismo rigor que el happy path. Mapeo de columnas, partial submit, drafts persistentes — son decisiones de UX, no de engineering.
- No empujes IA donde no aporta. El formulario seguía siendo más rápido para Jobs simples. Aceptarlo y diseñarlo así es la diferencia entre un producto que respeta a su usuario y uno que persigue una tendencia.
Esto fue un trabajo de equipo. Yo era el único Product Designer del producto, pero fue posible gracias a la colaboración constante con 7 engineers y varias rondas de user testing con operadoras reales en el mid-west y Texas. El Design System creció de 0 a 60-100+ componentes durante este periodo — sin esa pieza estructural, las tres rutas de input no se podrían haber lanzado con consistencia visual sin tirar el roadmap por la ventana.
Case study relacionado