La navaja de Feynman
(defenderofthebasic.substack.com)- Las explicaciones técnicas, aun cuando tengan en cuenta a principiantes, deben dejar pistas precisas para que una persona con capacidad de entender pueda captar el estado real
- El mensaje de error de Outlook le ofrece al usuario un modelo contradictorio al decir que puede copiar el contenido de un “mensaje que ya no existe”
- Si no se ocultan palabras como
serverycache, los usuarios interesados pueden buscarlas y aprender, y quienes ya las conocen entienden el problema más rápido - Indicadores de estado familiares pero imprecisos, como
loading…, ocultan lo que el sistema realmente está haciendo; es mejor decirlo de forma directa, como “esperando a que termines de escribir” - La simplificación excesiva impide que el usuario razone, así que hay que dejar al menos indicios que conduzcan a la verdad, como un código de error y posibles acciones
Una explicación fácil no debe ser incorrecta
- La “navaja de Feynman” es un criterio para explicar temas técnicos a usuarios generales: si ni siquiera una persona con capacidad de entender puede entenderlo, no es una buena explicación
- Richard Feynman dijo que, con solo la información de que era una “máquina de 7 toneladas” en un artículo periodístico, no podía saber de qué máquina se trataba, y que tampoco sabía a qué se refería “atomic bullet”
- Lo importante no es qué tan fácil parece la explicación, sino si quien la lee puede entenderla de verdad cuando tiene la capacidad de hacerlo
La confusión creada por un mensaje de error de Outlook
- En una discusión de Hacker News se burlaron del siguiente mensaje de error
- “This message can't be saved because it no longer exists. It can only be discarded. Make sure you copy the contents of the message before you discard if you want to use them later.”
- Al usuario se le dice que puede copiar el contenido de un mensaje que no existe, pero que no puede guardarlo
- El problema no es que el usuario general no conozca términos técnicos, sino que no se explica el estado real ni siquiera a quienes sí podrían entenderlo
No ocultar server ni cache
- Una redacción alternativa explica que el mensaje fue eliminado del servidor de correo, pero que Outlook lo conserva en el caché temporal de ese dispositivo
- El usuario puede copiar el contenido del mensaje o descartarlo del caché
- Si lo descarta del caché, se eliminará de forma permanente
- Algunas personas respondieron que los usuarios generales no entienden palabras como
cacheoserver - Sin embargo, esas palabras se convierten en pistas aprendibles que los usuarios interesados pueden buscar, y a quienes ya las entienden les muestran con más claridad la situación real
- Los usuarios sin interés no obtendrán mucha ayuda de ninguna explicación, pero para los interesados deben quedar pistas
Decir el estado del software tal como es
- La herramienta
substack-proxygenera una URL para evadir la censura de Twitter a partir de la URL de una publicación de Substack que el usuario copia y pega - Mientras el usuario escribe o modifica la URL, se producían demasiadas solicitudes al servidor, por lo que se agregó una demora de alrededor de 1 segundo
- El primer texto de estado era
loading…, pero en realidad no estaba cargando: estaba esperando a que el usuario terminara de escribir - “Esperando a que termines de escribir” refleja con mayor precisión el estado real de la máquina
- Incluso si se queda detenido por un error, quedar en “esperando a que termines de escribir” revela mejor el estado problemático que
loading…
No hace falta enseñarlo todo, pero sí ser fiel
- El software no necesita enseñárselo todo a todos los usuarios
- A menudo los usuarios no quieren saber la causa; solo quieren que funcione correctamente
- Aun así, si se ofrece una explicación, no debe dar un modelo extraño o impreciso de cómo funciona la computadora
- También es posible ofrecer solo un código de error simple y acciones
Error code 1027: file cannot be saved.[Copy contents][Delete file]
- Los usuarios interesados pueden buscar el código de error, y los no interesados pueden ver de inmediato las opciones disponibles
El criterio para simplificar
- Una buena simplificación no corta los indicios que conectan con la verdad que intenta explicar
- Es peligroso partir de la idea de que “el usuario promedio no lo entiende” y rebajar a todos los usuarios al mismo nivel
- “bits and bytes” es un caso que explicaba a personas que usaban una computadora por primera vez cómo encenderla y escribir
enter, y en el mismo episodio llegaba a tratar el código binario
1 comentarios
Opiniones de Hacker News
El ejemplo de message-doesn't-exist parece menos un caso de simplificación excesiva y más un error común que ocurre cuando quien escribe se olvida del contexto.
Desde el punto de vista de un programador, se intentó obtener algo del servidor y el servidor respondió que no estaba, así que “no existe” podría ser correcto.
Pero en el contexto en que el usuario está viendo ese mensaje frente a sus ojos, “no existe” es claramente falso.
Hay que volver a encuadrar el contexto, algo como: “Ese mensaje no está en el servidor y por ahora solo está temporalmente en tu computadora, así que cópialo”.
Aunque el usuario no sepa qué es un “servidor”, con la información de que “no está en algún lugar” la frase tiene mucho más sentido.
Si un mecánico señala todo el auto y dice “esto se va a reemplazar”, confunde; pero si dice “se va a reemplazar xxx”, se puede entender aunque uno no sepa qué es xxx.
Siento que el diseño online actual va todo en la dirección de hacer más tonta a la gente, bajo la suposición de que cuanto menos tenga que pensar el usuario, más fácil lo seguirá.
Por ejemplo, los resultados de búsqueda de Google parecen ajustarse cada mes más al mínimo común denominador, y aunque busques algo con matices, el algoritmo te empuja hacia respuestas que no ayudan.
Tal vez mucha gente realmente responda mejor a ese enfoque y por eso se vea bien en los datos, pero personalmente no me gusta.
Quiero aprender poco a poco al interactuar con un sistema y encontrarme con la complejidad; no quiero que esa complejidad se oculte.
Entonces hicieron que el equipo fuera ajustable, y el desempeño mejoró mucho y también se redujeron los errores.
Pero no entiendo por qué en la industria tecnológica se dice exactamente lo contrario: que cuanto más se ajusta algo a un usuario promedio imaginario, mejor es o más dinero da.
Me pregunto por qué se trata la diversidad individual como algo que puede ignorarse.
Si extraño Norton Disk Doctor no es porque me dedique a recuperar discos, sino porque tenía una interfaz que respetaba la inteligencia del usuario.
Otros sistemas relacionados con almacenamiento te lanzaban frases indescifrables como “Mode 5/7? [Y]”, o preguntas excesivamente tontas como “Are you sure? [N]”.
No había forma de saber de qué había que estar seguro, qué era el mode 5, si era el 7 o si eran ambos.
En cambio, Norton explicaba en varios párrafos qué significaba cada opción, desarrollaba los conceptos dentro de su contexto y avisaba sobre ventajas y riesgos.
En vez de hacerte apretar Y una y otra vez y dejarlo a la suerte, te permitía elegir con información.
Ese respeto por lectores y usuarios aplica a toda escritura técnica: manuales, interfaces de usuario, posts de blog, documentación de API.
En vez de simplificar el texto hasta hacerlo tonto para “la gente común”, me parece mejor educar para que toda persona que lo lea y lo entienda crezca un poco más técnicamente.
Por cierto, “Mode 5/7?” fue un mensaje real de un arreglo SAN Hitachi que contenía todos los datos de un ministerio, y el manual explicaba amablemente que esta opción activaba o desactivaba mode 5/7.
Si elegías mal, quizá el arreglo se borraba solo y se moría un gato, o quizá no pasaba nada. Quién sabe.
A quienes crean esas opciones les cuesta poquísimo agregar una breve descripción tipo tooltip a cada una, pero en la práctica casi nunca lo hacen.
Si el objetivo es transmitir información, es cierto.
Pero si el objetivo es aumentar clics, reducir consultas a soporte y subir el engagement, no es fácil decir que una explicación técnicamente específica y precisa sea mejor que una explicación simplificada hasta el punto de ser imprecisa.
Eso no significa que esté de acuerdo con priorizar el engagement por encima de transmitir información.
https://www.goodreads.com/quotes/65213-briefly-stated-the-ge...
Hay que hacer que perseguir esos objetivos se convierta en una decisión realmente riesgosa para quienes deciden hacerlo.
En el trabajo lucho mucho con este problema.
No puedo asumir que el lector domine el inglés, ni que entienda el tema, ni siquiera que tenga interés en entenderlo.
Por eso adoptamos una redacción clara y sin ambigüedades, y ahora estamos experimentando con formatos que permitan captar la idea principal con solo escanear el texto.
Personalmente, creo que nhs.uk es el mejor ejemplo del que se puede aprender.
La gente no es tonta: está ocupada, cansada, es floja o simplemente no le interesan demasiado los detalles.
Hay un equilibrio entre respetar la inteligencia del lector y respetar su tiempo.
https://www.gov.uk/guidance/content-design/writing-for-gov-u...
También pensé que la navaja de Feynman originalmente iba en esta dirección. Me vino a la mente una respuesta a una pregunta del público en una conferencia sobre QED en Nueva Zelanda, en 1979.
Ante la pregunta “¿Le gusta la idea de que nuestra imagen del mundo tenga que basarse en cálculos que incluyen probabilidades?”, Feynman respondió que él no dice que le guste o que no le guste.
Dijo que, tras una larga formación como científico, desarrolló una forma particular de ver las cosas, y que en una conferencia puede simplificar un poco y hacer una pequeña trampa para que suene como si no le gustara, pero que el significado real es que es “extraño”.
Dijo que él no piensa en si esto le gusta o no, sino en qué es y qué no es, y que si le gusta es algo totalmente irrelevante que eliminó de su cabeza.
En los temas de complejidad y de explicar a personas no expertas, la madriguera siempre se vuelve más profunda.
También hay una buena cita en la parte sobre rotaciones espaciales de las clases de Caltech. “No usaremos estas ecuaciones en su generalidad completa ni estudiaremos todos los resultados. Hacerlo tomaría años, y pronto tendremos que pasar a otro tema. En un curso introductorio solo podemos presentar las leyes básicas y aplicarlas a unas pocas situaciones de especial interés”.
Visto de forma positiva, es una actitud de no querer decir algo incorrecto ni insinuar algo que no sea cierto desde una posición de autoridad, pero al mismo tiempo también puede parecer que evita responder bien la pregunta.
En el video donde un entrevistador le pregunta cómo funciona un imán, responde exactamente de la misma manera.
Eso de “mi comentario favorito fue el de lisper…” está genial. Alguien me reconoció.
Estoy escribiendo con mucho empeño una serie de posts de blog sobre el método científico, pero casi no recibí feedback, y es raro que un comentario ligero como este reciba atención.
La vida a veces da risa.
El propio autor tampoco reprodujo correctamente la cita de Feynman.
No debería ser “And there are not sixty two kinds of particles”, sino “And there are now sixty two kinds of particles”.
Si se puede explicar de una forma que satisfaga tanto a principiantes como a expertos sin usar términos técnicos, ¿para qué sirven los términos especializados?
El ejemplo del texto no le sirve a ninguno de los dos lados, y no mejora con ni sin términos técnicos.
Simplemente es una mala explicación, así que el argumento en sí queda débil.
Hay que transmitirlo todo, o bien rodearlo mediante terminología especializada.
En algunos casos es posible una explicación que satisfaga a ambos lados, pero es más difícil y requiere más palabras. Al menos en el contexto de los medios, esto importa.
Aun así, aquí hay un espectro, y creo que normalmente se puede encontrar un punto medio adecuado.
Si surge confusión del tipo “¿se puede copiar el contenido aunque el mensaje no exista? Si se puede copiar, ¿por qué no se puede guardar? Si no existe, ¿por qué hay que descartarlo?”, quizá sea mejor escribirlo de forma menos explicativa.
Bastaría con algo como: “Este mensaje pronto dejará de estar disponible. Si quiere usarlo más tarde, copie su contenido antes de descartarlo”.
Sacar el tema de la caché no ayuda al usuario.
La verdadera solución es agregar al final del mensaje un botón que diga “Guardar el contenido del mensaje en el dispositivo”.
Así el texto queda claro y lleva directamente a una acción.
La explicación más detallada podría llevar una etiqueta, o estar en una segunda pantalla accesible mediante un botón de “explicación avanzada”.