¿Son los "errores" por diseño una mala señal?

¿Es una mala señal si los usuarios envían informes de errores para cosas que son por diseño?

¿Significa generalmente que la aplicación es confusa o poco clara, o debería atribuirla a un error único del usuario a menos que se indique específicamente?

(En realidad no tengo ningún informe de este tipo. Esta es una pregunta puramente hipotética sobre si la existencia de "errores" de diseño es o no algo malo).

¿Es una mala señal? Creo que es una advertencia que vale la pena analizar, pero también creo que seguramente sucederá.

Cuando la gente me envía algún tipo de comentario, trato de filtrarlo en tres categorías:

• Loco
• Peticiones de características
• Mala comunicación

Loco

Los errores son cuando algo obviamente no funciona de la manera que esperaría, ni de la manera que el usuario esperaría. Al igual que me pidió mi nombre, ingresé "Scott", presioné enter y dijo: "¡Hola Joe!"

Peticiones de características

Esto es como "Sé que nunca hablamos de esto, pero ¿puede el programa inferir de los gestos de mi mouse que soy zurdo y mover el botón Aceptar al lado izquierdo de la pantalla?" Esto es cuando el comportamiento actual coincide con sus expectativas y las del usuario , pero quieren cambiar las expectativas.

Mala comunicación

Esto es cuando se esperaría un resultado de un escenario, pero el usuario espera un resultado diferente. A veces esto se convierte en una solicitud de función, si simplemente no han comunicado sus expectativas, pero pensaron que lo hicieron. A veces esto se convierte en un error si se demuestra que su expectativa es incorrecta.

Sin embargo, muchas veces tienes conocimiento que el usuario no tiene. ¿Qué pasaría si dijeran: "En esta pantalla, puedo agregar un registro para mí dos veces con el mismo nombre y apellido! ¡Obviamente es un error!" Su respuesta podría ser: "Hay muchas personas en el mundo con el mismo nombre y apellido, por lo que no necesitamos que esa combinación sea única. Tenemos una tarea de limpieza que se ejecuta por la noche y envía por correo electrónico un posible informe de duplicados a servicio al cliente cuando cree que detecta un duplicado con un nombre y una dirección similares, y les pide que lo verifiquen manualmente ".

Por lo tanto, debe leer cada informe de error, pero la mayoría de los sistemas complejos tendrán informes de error que en realidad son solo solicitudes de características, o posiblemente una mala comunicación de los requisitos. No entender la complejidad subyacente del mundo real es probablemente la mayor fuente de estos problemas.

Esto no se mencionó en las respuestas anteriores hasta ahora, por lo que agregaré que también podría ser un signo de una base de usuarios ignorantes. No uso la palabra "ignorante" de una manera despectiva o condescendiente, simplemente como una forma de expresar que no tienen el conocimiento adecuado o la educación en su dominio o de las complejidades del software en sí.

La mayoría de los usuarios no son conscientes de cuán complicado debe ser el software para cumplir con ciertos requisitos. Algo en el sentido del 80% del esfuerzo se destina solo al 20% de la funcionalidad (casos marginales y excepcionales).

A veces no entienden por qué el software tiene que comportarse inherentemente de una manera determinada, muchas veces para evitar una multitud de defectos o corrupción de datos, etc.

Esto no es preocupante ya que esto mejora con una documentación y comunicación clara y concisa.

Si tiene un usuario experto en su campo, podría tener un problema importante. Imagine que un contador que encuentra que su software, por diseño, no sigue los procedimientos generales de contabilidad o un ingeniero que descubre que tiene una fórmula incorrecta. Esto no debería ser demasiado difícil de investigar para ver si son correctos. Rediseñe y corríjalo si es necesario, rápido.

Se debe considerar una opinión sobre una característica de IU particular o un campo que creen que debería tener un símbolo de moneda o algún otro formato, al menos hasta que obtenga más comentarios. Investigar esto podría ser un poco más difícil.

Los errores de diseño en mi experiencia significan que sus casos de uso no se ajustan a sus usuarios reales. Intente leer sobre el uso de usuarios reales para sus casos de uso (solo darles nombres y una descripción en miniatura hace maravillas para la calidad de los casos de uso).

Cuando los proveedores prominentes de sistemas operativos dicen "este comportamiento es por diseño", generalmente tenían en mente la facilidad de implementación o la ventaja comercial. Si no es usted, intente descubrir el conjunto de habilidades y la relación real de sus usuarios con su software. ¿Lo usan todo el día? Por diversión ? ¿Una vez a la semana porque reemplazó los formularios TPS?

La interfaz de usuario debe seguir el Principio de Menos Asombro : los informes repetidos de errores en una característica que funciona según lo diseñado son una indicación de que este principio no se ha cumplido correctamente.

Hay dos tipos de errores: la funcionalidad no coincide con las intenciones del programador, o la funcionalidad no coincide con los requisitos. Los programadores tienden a centrarse en lo primero en detrimento de lo segundo. En pocas palabras, si sus usuarios informan una gran cantidad de "errores de diseño", sus requisitos no son lo que usted cree que son.

No necesariamente. Podría ser que el error reportado está en un uso del software que está fuera de su alcance originalmente definido. Considere el software que fue diseñado para hacer A, B y C (para un ejemplo trivial, dibuje líneas, triángulos y rectángulos). Si D es un próximo paso lógico (por ejemplo, pentágonos), el usuario puede asumir que también debería hacerlo, y que no hacerlo es un error. Pero si esto está fuera del alcance original, no es un error. En cambio, podría ser un descuido (error) en el diseño, o un área gris en las especificaciones, o un conjunto diferente de suposiciones hechas por el desarrollador y el usuario.

(Editar: agregué mi comentario a la respuesta según la sugerencia de @Marjan Venema.

Creo que es una mala señal principalmente debido al hecho de que el diseño no es genérico y los requisitos de los usuarios no se entienden / analizan completamente.

Veo dos categorías de diseño: Diseño por accidente. - Diseño por intención.

El diseño por accidente conduce a tales problemas con frecuencia y no puede sostenerse.

Me gustaría agregar a la respuesta de maple_shaft sobre la "ignorancia" de los usuarios. También debe tener en cuenta que el 90% de los usuarios solo se preocuparán por su propia experiencia y forma de usar el sistema. No les importan otros usuarios, ¿por qué deberían hacerlo? Nuestro trabajo como diseñadores / desarrolladores es recibir los aportes de todos los diferentes tipos de usuarios y hacer algo que se adapte a todos lo mejor posible. La mayoría de las veces no se puede hacer una solución óptima para todos.

¡Pero, por supuesto, necesita leer y evaluar los comentarios de sus usuarios! ¡Son, después de todo, los que usan tu creación!

Los usuarios que enviaron las solicitudes de error generalmente no fueron consultados sobre el diseño, por lo que no es sorprendente que vean las cosas como errores que fueron decisiones de diseño deliberadas. Para un usuario, cualquier cosa que no funcione como se espera es un error.

He descubierto que el problema es a menudo una señal de que BA o PM solo recibió requisitos de gerentes, no de usuarios reales. Lo que los gerentes esperan del sistema a menudo es muy diferente de lo que realmente necesitan las personas que ingresan los datos. Me enseñaron a recopilar datos directamente de los usuarios reales, pero la mayoría de los BA con los que me he encontrado últimamente solo hablan con los gerentes (y, en general, con los gerentes relativamente mayores).