Cómo obtener un informe de errores útil de alguien sin conocimientos técnicos

Alguien sin conocimientos técnicos no es un mal reportero. Está respondiendo una pregunta diferente a la que hiciste, y generalmente el problema fue la pregunta.

Casi todos los formularios de informe de errores piden las mismas tres cosas: qué salió mal, los pasos para reproducirlo, y qué esperabas que pasara en su lugar. Cada una de esas preguntas le pide al reportero que haga un análisis. “Qué salió mal” pide una causa. “Esperado versus actual” les pide que sepan qué se suponía que debía hacer el software, que es el conocimiento que no tienen y la razón por la que te están escribiendo. “Pasos para reproducir” les pide que hayan estado prestando atención a una secuencia que no merecía atención hasta que falló.

Lo que una persona puede darte con precisión es lo que estaba intentando hacer y lo que vio. Esas son observaciones. La mayoría del resto del formulario es una solicitud de una teoría.

La teoría es la parte a dejar de lado

Lo costoso en un informe sin capacitación no es el detalle faltante. Es la explicación, porque una explicación llega pareciendo una observación y pasarás la mañana dentro de ella.

“Me cerró la sesión” es una conclusión. Debajo de ella, lo que realmente pasó es que aparecía una pantalla con un formulario de inicio de sesión en ella. Esa pantalla tiene al menos cuatro causas que no tienen nada que ver entre sí: la sesión realmente expiró, una llamada API devolvió un 401 y el cliente redirigió en ella, se sirvió una página en caché con el encabezado de cierre de sesión, o tenían una segunda pestaña abierta y cerraron la sesión en esa. Comienza desde “cerró la sesión” y vas al almacén de sesiones. Comienza desde “una pantalla de inicio de sesión apareció mientras estaba en medio del pago” y tienes el tiempo, la página y el síntoma, y el almacén de sesiones es uno de cuatro lugares para mirar en lugar del único.

Débil

El sitio me cerró la sesión mientras estaba pagando.

Mejor

Estaba en el paso de pago y la página volvió al formulario de inicio de sesión. Mi carrito seguía ahí después.

Nada en la versión mejor requiere ningún conocimiento técnico. Es la misma persona, se le pregunta qué vio en lugar de qué significaba.

Palabras que no significan lo que asumes

El vocabulario es compartido y las definiciones no. Estas cinco hacen el daño más grande porque ambos lados están seguros de que se entendieron mutuamente.

Se bloqueó

La pestaña se cerró, la página quedó en blanco, un spinner nunca se detuvo, o el navegador en sí se cerró.

Se congeló

Nada respondió a los clics, o algo estaba cargando sin indicación de que lo estuviera.

Eliminado

Desapareció de la lista frente a ellos. Puede estar filtrado, en otra página, en otra cuenta, o genuinamente eliminado.

Página

Una URL, una pestaña, un modal, un paso en un flujo, o todo el sitio.

Error

Un mensaje que escribiste, una pantalla de error del navegador, o simplemente un resultado que no querían.

No puedes arreglar esto publicando un glosario, porque nadie lee uno antes de reportar un problema. Lo arreglas nunca haciendo una pregunta cuya respuesta es una de estas palabras. “¿Se bloqueó?” no tiene una respuesta útil. “¿Qué había en la pantalla cuando dejó de funcionar?” sí.

Pregunta sobre la última cosa que funcionó

La pregunta más productiva a hacer a alguien sin el vocabulario no es sobre la falla en absoluto.

Pregunta qué estaban haciendo inmediatamente antes, y pregunta si alguna vez ha funcionado. Ambas son cosas que una persona recuerda sin esfuerzo, y entre ellas acotan el problema: la primera te da el punto de entrada, y la segunda te dice si estás mirando una regresión o algo que nunca funcionó para esta persona en esta situación. Una función que funcionó para ellos el martes pasado y no hoy es una investigación diferente de la que nunca han visto funcionar una sola vez.

“¿Alguna vez ha funcionado para ti?” también hace algo que las otras preguntas no hacen. Es respondible con un sí o un no, así que casi siempre se responde.

Pregunta por la pantalla, no por una descripción

Una captura de pantalla es el único artefacto que alguien sin capacitación produce de manera confiable y precisa, porque tomar una no requiere vocabulario en absoluto. Contiene cosas que no pudieron haberte dicho aunque hubieras preguntado: la URL en la barra de direcciones, el ancho de la ventana, qué cuenta está conectada, la redacción exacta del mensaje, si un banner estaba cubriendo el botón. La mayoría de lo que hubiera extraído durante cuatro correos electrónicos está en una imagen que les tomó cinco segundos.

Entonces “¿podrías enviarme una imagen de lo que estás viendo?” vale más que cualquier pregunta que pudiera escribir, y es lo más fácil en la lista para pedir.

El límite vale la pena conocer también. Una captura de pantalla muestra la superficie en un momento. No puede decirte qué hacía el navegador debajo, y la falla a menudo no deja ninguna marca en la superficie: una solicitud que devolvió un 500 mientras la página se veía normal es invisible en una imagen.

Lo que no pueden darte, y no se les debe pedir

Errores de consola, el registro de red, la versión del navegador, el tamaño de la ventana gráfica. Estas son las cosas que realmente acortarían la investigación, y cada una requiere que el reportero abra una herramienta de desarrollador y sepa qué buscar.

Pedirlo tiene un costo real y no es el tiempo del reportero. Es que la solicitud se lee como una prueba. Alguien que no puede encontrar la consola ahora sabe que no logró ayudar adecuadamente, y lo siguiente que nota es lo que se guardan para sí mismos. El suministro de personas dispuestas a contarte sobre un problema es pequeño y completamente voluntario, y es más fácil de perder que de construir.

La respuesta honesta es que esta mitad debe ser recopilada en lugar de solicitada.

No escribirá el título por ti, y no puede decirte qué estaba intentando hacer la persona. Esa parte solo viene de preguntarles, que es por qué las preguntas importan.

Pregunta una a la vez

Una lista de seis preguntas vuelve con dos respuestas y sin indicación de cuales cuatro se omitieron. Peor, se lee como un formulario, y un formulario es algo que la gente pospone hasta el fin de semana.

Envía una pregunta. Cuando se responda, envía la siguiente si aún la necesitas. Se siente más lento y no lo es, porque la alternativa es un largo silencio seguido de una respuesta parcial que genera tres preguntas más de todas formas.

Ten en cuenta qué estás interrumpiendo. Un informe de errores es el final de una cadena de pequeñas decisiones para molestarse: lo notaron, decidieron que no fue su culpa, descubrieron dónde decirte, y lo escribieron. Cada intercambio después de eso es otra oportunidad para que la cadena se rompa, y nada te dice cuándo lo hace. Solo nunca vuelves a escuchar, lo que desde tu lado es indistinguible del problema habiendo desaparecido.

Las preguntas, en el orden para hacerlas

Cuatro preguntas, ninguna de las cuales requiere que la persona sepa nada sobre software:

• ¿Qué estabas intentando hacer?
• ¿Qué viste en su lugar? Si puedes, envía una imagen de ello.
• ¿Cuándo fue esto, más o menos, y qué estabas usando en ese momento?
• ¿Alguna vez ha funcionado para ti antes?

Si obtienes esas cuatro, tienes el punto de entrada, el síntoma, una ventana para buscar en tus registros, y si es una regresión. Eso es suficiente para comenzar, y es más de lo que la mayoría de los tickets escritos por personas que sí conocen el vocabulario.