Ministerio del Usuario
No, pará. No es (sólo) que sea un quisquilloso

Cuando elegís grabar en lugar de escribir, estás tomando una decisión de diseño sobre la interacción: decidís que tu comodidad para “soltar” información es más importante que la capacidad del otro para procesarla.
El bloqueo del contexto: ¿Y si estoy en una reunión?
Hay una variable que el fanático del audio ignora: la multitarea visual. Hoy, un profesional pasa gran parte de su día en videollamadas.
Si me mandás texto mientras estoy en una reunión, puedo leerlo en una segunda pantalla, procesarlo y responderte sin perder el hilo de mi llamada. Es asíncrono y silencioso.
Si me mandás un audio, me bloqueás. No puedo reproducirlo sin interrumpir mi audio actual (o sin que salga por los parlantes). Ese mensaje de “urgencia” queda atrapado en un limbo hasta que yo tenga un hueco de silencio.
Al elegir audio, convertiste una respuesta de 30 segundos en una demora de 4 horas. Creíste que ganabas tiempo al no escribir, pero frenaste el flujo de resolución del problema.
La transferencia de la complejidad (Ley de Tesler)
La Ley de Tesler dice que la complejidad en un sistema es constante; si no la asumís vos, la asume el otro. Al enviar un audio, te ahorrás el trabajo de estructurar, sintetizar y redactar. ¿A dónde va ese trabajo? Al receptor.
Le transferís la carga cognitiva de decodificar, filtrar el ruido, retener datos en la memoria de trabajo y linealizar una información que debería ser de acceso rápido. Vos te sacás el problema de encima; el otro se queda con el problema de entenderte.
La ineficiencia matemática: Desglose GOMS
Para los escépticos, apliquemos el modelo KLM-GOMS (Keystroke-Level Model), el estándar en ingeniería de usabilidad para predecir tiempos de tarea.
Variables estándar:
- M (Mental Operator): 1.35 seg (Decidir qué hacer).
- P (Pointing): 1.10 seg (Mover el dedo al control).
- K (Keystroke): 0.20 seg (Tocar la pantalla).
- W (Wait/System Response): Tiempo que el sistema te obliga a esperar.
Escenario A: Escuchar tu audio de 2:34 min (154 seg)
El usuario es rehén del tiempo. La tarea se vuelve pasiva.
Fórmula: M + P + K + W
Cálculo: 1.35 + 1.10 + 0.20 + 154 = 156.65 segundos.
Factor crítico: El operador W (Wait) domina el 98% de la interacción. El usuario no puede acelerar el proceso significativamente sin perder información.
Escenario B: Leer el mismo contenido (Escaneo visual)
Un audio de 2:34 min tiene aprox. 360 palabras. Un humano no “lee” letra por letra en un chat, escanea buscando keywords a una velocidad de 700 palabras por minuto.
Fórmula: M + T(Tiempo de lectura)
Cálculo: 1.35 + (360 palabras / 700 wpm) = 32.2 segundos.
Resultado:
Estás obligando a tu interlocutor a un proceso casi 5 veces más lento (156 vs 32 segundos) y cognitivamente más costoso, solo para ahorrarte el esfuerzo de tipear.
La falacia de “Bueno, ponele transcribir y listo”
Acá aparece siempre la defensa clásica: “Que use la función de transcribir del teléfono”. Eso es un parche técnico a un problema de usabilidad humano.
Una transcripción automática convierte audio en caracteres, pero no convierte habla en escritura. El lenguaje oral es redundante, desordenado y repetitivo. El lenguaje escrito es estructurado y sintetizado.
Cuando le decís al otro “transcribilo”, le estás entregando un bloque de texto sin formato ni jerarquía. Le seguís tirando “datos crudos” en lugar de “información procesada”. La deuda cognitiva sigue impaga.
La pregunta final
Antes de apretar el micrófono, hacete estas preguntas:
- ¿Querés comunicar o querés sacarte un tema de encima?
- ¿Querés transmitir tu estado de ánimo o querés transmitir información?
- ¿Querés que te entiendan o simplemente querés hablar?
- ¿La comunicación termina cuándo emitís tu mensaje o cuando el otro lo entiende?
Si la respuesta es transmitir información clara, escribí. Si mandás un audio cuando te piden texto, no estás comunicando; estás tirando el problema del otro lado de la pared.