Skip to main content

Someone wanted to learn this too, so Grasp built them a personal learning path.

You can keep exploring this one or create your own

Segmentación de Usuarios por Función, Contexto y Necesidades

Hola. En la lección anterior delimitamos una oportunidad posible: ayudar a clasificar y resumir consultas de acceso antes de que un agente las resuelva. Pero «el agente» no describe a todas las personas que podrían usar esa ayuda. Algunas trabajan ante un ordenador con tiempo para revisar un borrador; otras atienden incidencias entre tareas, desde un móvil. La misma solución puede encajar bien en un contexto y resultar impracticable en otro.

En unos 40 minutos aprenderás a segmentar usuarios por la tarea que desempeñan, sus condiciones de trabajo, lo que necesitan para hacerla bien y las barreras que encuentran al incorporar IA. El objetivo es producir segmentos útiles para decidir a quién escuchar y qué comprobar, no etiquetas que definan permanentemente a las personas.


Segmentar empieza por el trabajo, no por la actitud

Una función indica qué responsabilidad tiene alguien en el flujo: atender consultas, resolver incidencias especializadas o supervisar la calidad. El contexto explica en qué condiciones cumple esa responsabilidad: dispositivo disponible, interrupciones, tiempo por caso, documentación accesible y margen para corregir errores. Ambas dimensiones importan. Dos personas con el mismo cargo pueden necesitar experiencias distintas si una trabaja con varios sistemas abiertos y la otra solo dispone de un móvil durante breves intervalos.

Este fragmento de CareerFoundry introduce el entorno de uso y la idea de situar a una persona ante una tarea concreta. Su ejemplo procede del diseño de productos de consumo; quédate con las preguntas sobre dispositivos, lugar, momento y objetivo, no con la información biográfica que no ayuda a decidir una adopción laboral.

How To Create A User Persona (Video Guide)

«How To Create A User Persona», de CareerFoundry, muestra cómo pasar de un perfil genérico a un contexto de uso y un escenario.

Mira el entorno para identificar condiciones físicas, sociales y técnicas. Después, en objetivo y escenario, observa cómo se concreta qué intenta conseguir el usuario y cuándo interactuaría con la herramienta.

Volvamos al flujo de consultas de acceso. Antes de crear segmentos, preguntaría: ¿quién recibe la consulta, quién puede verificar la información y quién responde si hay una excepción? No basta con que todos pertenezcan al mismo equipo. Tampoco basta con llamar «usuarios de IA» a quienes tienen una cuenta: una persona podría consultar resúmenes, otra aprobar cambios de permisos y otra revisar la calidad del servicio. Sus necesidades son diferentes porque sus tareas y responsabilidades lo son.


De hipótesis internas a segmentos respaldados por evidencia

Una persona o perfil de usuario es una síntesis memorable de patrones compartidos, no una biografía inventada que sustituya la investigación. Para este puesto interesa un perfil breve que permita tomar decisiones: «agentes que resuelven consultas durante una jornada con muchas interrupciones» es más útil que una descripción de su edad o sus aficiones.

La lectura siguiente distingue entre protopersonas, que hacen explícitas las suposiciones del equipo, y personas cualitativas, construidas a partir de lo que cuentan y hacen usuarios reales. Esa distinción evita presentar una primera conversación con responsables como si ya representase a toda la plantilla.

3 Persona Types: Lightweight, Qualitative, and Statistical - NN/G

Lee la explicación de Nielsen Norman Group para distinguir una segmentación provisional de otra fundamentada en investigación.

En la introducción, justo antes de «Proto Personas: Meant for Quick Alignment», lee el propósito de las personas. En «Proto Personas: Meant for Quick Alignment», incluidas «How Proto Personas Are Made», «Pros of Proto Personas» y «Cons of Proto Personas», empieza donde dice «Proto personas are a lightweight form» y sigue hasta su uso provisional. Continúa en «Qualitative Personas: The Best Fit for Most Teams» y «How Qualitative Personas Are Made»: desde «Start by interviewing 5» hasta patrones y límites. Fíjate en por qué unas entrevistas revelan motivos, pero no permiten calcular qué porcentaje de toda la plantilla pertenece a cada perfil.

¿Cómo lo aplicarías sin convertir el descubrimiento en un proyecto interminable? Comienza con el mapa del flujo de la lección anterior. Para cada función que interviene, contrasta lo que supone el equipo con conversaciones breves y, cuando sea posible, con la observación de casos de trabajo. Pide que te describan un caso reciente, no que opinen en abstracto sobre «la IA».

Puedes explorar cuatro preguntas en ese orden:

  1. Función: ¿qué parte del caso resuelves y qué decisiones no puedes delegar?
  2. Contexto: ¿cuándo aparece esa tarea, con qué dispositivo e información trabajas y qué interrupciones son habituales?
  3. Necesidad: ¿qué resultado te permitiría resolverla mejor sin perder control ni calidad?
  4. Barrera: ¿qué te impediría usar esta ayuda precisamente en ese momento?

Después compara respuestas: ¿varias personas comparten una necesidad y una dificultad relevantes, aunque tengan cargos distintos? ¿Personas con el mismo cargo difieren porque una dispone de acceso y tiempo de revisión y la otra no? Agrupa por patrones que cambien una decisión de adopción, no por cada diferencia individual. Los registros de uso pueden mostrar quién accede y cuándo, pero una cifra de accesos no explica por sí sola por qué alguien usa poco la herramienta. Las entrevistas tampoco permiten asignar porcentajes fiables a los segmentos sin más investigación.


Cuatro dimensiones en un mismo mapa

Este ejemplo es hipotético: sirve para ver cómo quedaría una primera segmentación del flujo de consultas, no para afirmar que esos grupos existen en un cliente concreto.

Función y contexto Necesidad ligada a la tarea Posible barrera que habría que comprobar
Agentes de oficina que revisan tickets en ordenador Entender mensajes largos y localizar instrucciones vigentes sin perder el hilo del caso. El resumen obliga a volver al mensaje original porque omite datos decisivos.
Personal de primera línea que consulta incidencias entre otras tareas, quizá desde móvil Encontrar una instrucción breve y saber cuándo derivar. La interfaz o el acceso no funcionan bien en sus momentos reales de trabajo.
Especialistas que tratan excepciones y datos de acceso Recibir el contexto correcto del caso y conservar las comprobaciones exigidas. No queda claro qué información ha consultado la IA o si está autorizada para mostrarla.
Responsables que supervisan la resolución Distinguir una mejora real de respuestas simplemente más rápidas. No disponen de señales suficientes para detectar errores o retrabajo.

Fíjate en que la tercera columna contiene hipótesis, no diagnósticos. Una persona que no usa una función puede desconfiar de su calidad, carecer de acceso, no tener tiempo para aprenderla o, sencillamente, no recibir casos en los que resulte útil. Llamarla «resistente» a partir de ese dato sería precipitado.

Una ficha breve para cada segmento puede conservar lo esencial:

Segmento provisional: personal de primera línea que consulta instrucciones entre tareas.
Tarea y contexto: resolver o derivar una incidencia en un intervalo corto; dispositivo y acceso pendientes de confirmar.
Necesidad: identificar una instrucción aplicable y sus límites.
Barrera hipotética: el recorrido de consulta requiere más tiempo o pasos de los disponibles.
Evidencia pendiente: observar casos reales y preguntar en qué momento abandonan la consulta, si ocurre.

La última línea mantiene el perfil abierto a corrección. Si descubres que el problema es una instrucción desactualizada para todos los usuarios, quizá no necesites un segmento nuevo: necesitas corregir una fuente común.


La disposición hacia la IA añade información, pero no reemplaza la función

Hasta ahora hemos segmentado según el trabajo. También conviene observar la relación de las personas con la herramienta: ¿han podido probarla?, ¿la incorporan a casos reales?, ¿confían en sus resultados?, ¿qué experiencia explica esa confianza o desconfianza? BCG describe perfiles de adopción para mostrar por qué un despliegue uniforme puede pasar por alto barreras distintas. Su análisis incluye investigaciones con desarrolladores de software: sus perfiles son una guía para formular preguntas, no una clasificación demostrada para cualquier equipo de atención, RR. HH. o primera línea.

AI Adoption Puzzle: Why Usage Is Up But Impact Is Not | BCG

Lee el análisis de BCG para ampliar el mapa de tareas y contextos con factores como confianza, oportunidad de aprendizaje y apoyo cercano.

En «The Personal Adoption Journey», lee desde «While the five stages may help clarify employees» hasta la segmentación. A continuación, en los perfiles «The AI Champion», «The Independent Explorer», «The Organizational Adopter», «The Passive Observer» y «The Cautious Skeptic», lee desde «Champions are the visible trailblazers of AI adoption.» hasta los cinco perfiles. Pregúntate qué diferencias podrías observar y cuáles exigirían hablar con las personas antes de atribuirles una motivación.

La imagen siguiente propone otro modelo, referido a adopción de IA en RR. HH. Usa dos ejes: grado de uso e integración, y sentimiento positivo. No coincide exactamente con los cinco perfiles de BCG; ambos son maneras de orientar la observación, no pruebas que deban encajar entre sí.

Matriz de cuatro perfiles de adopción de IA en RR. HH. según uso e integración (eje vertical) y sentimiento positivo (eje horizontal): usuario reticente, evitador escéptico, champion de adopción y explorador activo.

La matriz ayuda a detectar un error frecuente: usar mucho no equivale a confiar. Alguien puede emplear la herramienta porque su tarea lo exige y, aun así, haber encontrado fallos importantes. A la inversa, una persona interesada puede usarla poco porque no tiene acceso, tiempo o un caso de uso autorizado. Incluso una crítica firme podría identificar un riesgo real que el proyecto necesita resolver.

Por eso conviene combinar ambas perspectivas. Primero identifica qué trabajo y condiciones comparten las personas. Después investiga qué les facilita o impide incorporar la IA dentro de ese contexto. No asignes un perfil psicológico a cada individuo ni trates las categorías como permanentes: la experiencia con la solución y las condiciones de trabajo pueden cambiar.


Qué debe entregar esta segmentación

Al cerrar el descubrimiento, procura que cada segmento pueda responder a una pregunta práctica: «¿Qué necesitaríamos comprobar o adaptar para que esta función pudiera realizar bien su tarea con la solución?» Un conjunto pequeño de fichas contrastables suele servir mejor que muchos perfiles decorativos. Indica en cada una qué procede de observación o entrevistas y qué sigue siendo una suposición; si dos fichas llevan a las mismas decisiones, probablemente puedan unirse.

También deja visible quién falta por escuchar. Si solo entrevistas a quienes ya utilizan IA desde un ordenador, podrías pasar por alto al personal con acceso intermitente, a especialistas que gestionan excepciones o a quienes deben verificar resultados. Segmentar no consiste en dividir a toda costa, sino en evitar que el usuario más visible represente por accidente a todos los demás.


Para cerrar

Una segmentación útil combina función, contexto de trabajo, necesidad y barrera comprobada o hipotética. Parte de las tareas reales, contrasta las suposiciones con usuarios y observación, y usa los perfiles de actitud hacia la IA como preguntas adicionales, nunca como etiquetas definitivas. El resultado es un mapa revisable que explica por qué una misma solución puede requerir condiciones distintas para aportar valor.

En la próxima lección usarás este conocimiento de los usuarios, junto con el análisis del flujo, para comparar oportunidades de IA por valor, viabilidad y riesgo.

Can't find a good explanation? Sign up and we'll make it for you

Sign up