Arquitectura de la información / Seguridad informática / microartículo
El principio de la inevitabilidad aplastante — Trabajo en seguridad informática
Haz que las conexiones sean tan evidentes que completar el trabajo resulte inevitable.
Los enlaces, los identificadores compartidos y los estados explícitos deben guiar al usuario por el proceso. El usuario no debería tener que reconstruirlo.
01 / El proceso es sencillo
Se sube, se lee y se acepta un documento. Entonces puede comenzar una tarea. En seguridad, el revisor necesita las pruebas, la aprobación pertinente y la tarea que respaldan. Las relaciones son el trabajo.
02 / Los enlaces se quedan a medias
La tarea enlaza con la aceptación del documento. Ahí se acaba el rastro. No hay referencia al documento propiamente dicho. Al usuario le toca reconstruir el resto.
03 / Otra pestaña. Otra investigación.
Hay una pestaña de Aprobaciones. Se listan por aprobación superior, así que el revisor tiene que profundizar hasta encontrar la suya. Sigue sin haber referencia al documento que necesita revisar. Otra pestaña no es otra conexión.
04 / Un nombre no significa que haya documento
Se pueden dar nombres a documentos sin subirlos. Se pueden subir documentos sin darles nombre. Ni la presencia ni la ausencia de un nombre te dice si existe un archivo. Pulsa cada enlace. Averígualo.
05 / El usuario aporta la arquitectura que falta
El revisor establece las conexiones, recuerda los registros y comprueba si existen las pruebas. La aplicación ya contiene la información necesaria. Pero su interfaz crea una investigación previa a la revisión de verdad.
06 / Conserva la identidad
T-3096 → PA-3096 → CA-3096[aa–zz] → D-3096[aa–zz]
El número de tarea y la designación correspondiente siguen siendo reconocibles entre registros. Necesitas el identificador de la tarea y tu designación. Muestra también el nombre de la persona. Joder, hazlo útil.
07 / Reconocer y navegar van juntos
El identificador te dice a qué tarea pertenece un registro. El enlace te lleva allí. El estado te dice si el documento se ha subido, leído o aceptado. Sigue el trabajo en vez de investigar la aplicación. La aceptación registra una decisión; el documento aún tiene que justificarla.
08 / Una explicación caritativa
Está claro que los desarrolladores, responsables, diseñadores, creadores de procesos y quizá el director de desarrollo desprecian al equipo que utiliza la aplicación. Tal vez a toda la humanidad. Tal vez a toda forma de vida.
O nunca tienen que usar la mierda que han desarrollado. O se diseñó para otro público. O —y esta es la que yo elijo— lo único que tienen que hacer es beber café y tumbarse en pufs.
09 / La prueba del idiota
Dale a alguien una tarea real sin un desarrollador narrando la interfaz. ¿Puede encontrar el documento, entender su estado y continuar? Si la aplicación hace que una persona competente se sienta idiota, examina la aplicación.
El siguiente paso debe ser evidente, los registros reconocibles y los datos necesarios accesibles. El usuario tiene trabajo que hacer.
Relacionado: Biblia de producción de cómics · El principio de la inevitabilidad aplastante — Escribir guiones de cómic