Este artículo proviene de un motor de traducción automática.
No me hagan hablar
El paciente sabe lo que está mal con él
Oigo la misma queja en cada clase de interfaz de usuario que enseño: "los usuarios no saben lo que quieren. ¿Cómo podemos construirlo que si no nos dicen?"
Esto no es un problema nuevo. En mi primer trabajo, mi jefe entregada alrededor de un poema titulado "T'was the Nite antes de aplicación" (bit.ly/189U65). Terminó con las líneas:
Y el usuario exclamó con un gruñido y una burla,
"Es justo lo que pedí, pero no lo quiero!"
Eso fue hace 30 años, y dudo que el poema era nuevo entonces.
Los usuarios tienen información valiosa para nosotros. Su satisfacción es nuestra métrica de máxima calidad. Pero los usuarios no saben cómo diseñar interfaces de usuario, de la misma manera que los pacientes médicos no saben diagnosticar sus propias enfermedades. Nos dicen si algo se siente bien o mal una vez que les pides. Pero tirando el diagnóstico correcto fuera el vacío no es su problema. Es nuestra, profesionales capacitados que pretendemos ser.
Piense en ello. Cuando un paciente va al médico, normalmente no dice, "Creo que tengo tipo c lepra fulminante, Kaminski variación". Lol Dice algo como, "Ay, mi codo duele." Es trabajo del doctor para averiguar si me duele el codo del paciente porque con cáncer está corroyendo sus huesos, su esposa de engaño sobre él y está desplazando a ansiedad o tal vez él sólo golpeado lo sobre algo. Es una habilidad difícil de aprender, y médicos que pueden hacerlo bien son buenos médicos.
Mi padre, un médico jubilado, proviene de la antigua escuela de medicina, que se adhiere a esta creencia: la información que necesita para hacer el diagnóstico es en la cabeza del paciente. Pero el paciente no sabe qué piezas son importantes, o cómo relacionar una pieza a otra. ¿Es trabajo del médico a formular las preguntas correctas: "cuando hizo su codo Inicio lastimar? ¿El otro codo duele demasiado? ¿Le duele al doblarla de esta manera? Así?" Pruebas de laboratorio e imágenes podrían confirmarlo, pero todo diagnóstico proviene de entrevistar y examinar al paciente.
Asimismo, es nuestro trabajo para formular las preguntas correctas, extraer los datos relevantes de las cabezas de nuestros usuarios y utilizarlo para construir una buena UX. Necesitamos aprender a entrevistar a los usuarios de nuestros destino y observarlos a trabajar. UX diseñadores que pueden hacer que son bien buenos diseñadores.
También es importante distinguir entre síntoma y causa. Mi padre dice la siguiente historia acerca de uno de los primeros pacientes que nunca trató. La tinta no era incluso seca en su M.D. Diploma como empezó su primer trabajo en la clínica del hospital. (Flamantes médicos fueron llamados a pasantes en aquel entonces, antes de que Bill y Mónica le dio a este término un significado diferente.)
Un paciente llegó quejándose, "No he tenido un movimiento intestinal en una semana." "OK," pensaba a mi papá. "Movimiento intestinal. No hay problema. Cuatro años de la escuela de medicina; Yo puedo manejar esto." Prescribe un laxante suave; no pasó nada. Trató de una más fuerte; todavía no hay nada. Obteniendo un poco frustrado, trató de un enema. Nada nuevo. Un ultrasonido fue negativo, una resonancia magnética no muestra nada y sangre fue nada destacable.
Conseguir a la desesperada, tomó al paciente hasta el quirófano e hizo una laparotomía exploratoria; rodajas de abrir su abdomen para mirar a su alrededor. No había nada para ver: el paciente tenía un vientre completamente normal. Finalmente, hizo lo que debió haber hecho en primer lugar: tuvo una historia completa, durante el curso de que preguntó al paciente lo que hizo para ganarse la vida. El paciente dijo: "Soy un músico". Por último, la bombilla de luz brilló sobre. "Ah! ¡ Por supuesto!"exclamó a mi papá. "Mira, aquí está 10 bucks. Ir a usted comprar algo de comer".
Lo mismo ocurre con nuestra población de usuarios. Ellos tienen alguna noción de lo que duele: "trabajé durante tres horas, luego arriba llegó este estúpido cuadro diciendo, 'Microsoft Word ha detectado un error y debe cerrar ', y todo mi trabajo se había ido". No es su trabajo para decir, "Jeez, ojalá algún personaje animado con cejas tupidas sería pop up y decir, ' parece que estás a punto de chocar. No creo que debeis guardar tu trabajo?'" Es nuestro trabajo averiguar lo que realmente está lastimando, por lo que podemos hacer que pare.
David S. Platt enseña programación .net en extensión de la Universidad de Harvard y en empresas de todo el mundo. Es el autor de 11 libros sobre programación, entre ellos “Why Software Sucks”, (Addison-Wesley Professional, 2006) e “Introducing Microsoft .NET”, (Microsoft Press, 2002). Microsoft lo nombró “Leyenda del software” en 2002. Él se pregunta si debería amarrar dos dedos de su hija con cinta para que aprenda a contar en octal. Puede contactar con él en rollthunder.com.