Epidemiología del software: el UXuario cero
En ciencias de la salud, el paciente cero es el primer caso que genera la atención suficiente para comenzar una serie de acciones de investigación y de contingencia, con el objetivo de comprender y mitigar una infección.
No necesariamente es la primera persona infectada, sino aquella que recibe atención sanitaria por primera vez. Cabe la posibilidad de que sea demasiado tarde y el daño causado ya sea significativo.
En la escuela clásica de la ingeniería de software, el paciente (usuario) cero es el cliente y/o usuario final. Aquí ya es tarde y la infección se esparcirá como herpes en concierto de Maluma. Entonces:
¿Quién es el usuario cero en todo proyecto de software? El desarrollador.
Para concluír con la analogía pretenciosa, atención médica es UX/UI para propósitos de esta publicación. Esto es, las prácticas de UX no comienzan con los desarrolladores, lo que provoca un deterioro rápido en la salud del proyecto, permeando cada una de las fases con nuevos síntomas y una mayor inmunidad a cualquier acción de contingencia.
El primer usuario de todo tipo de software es el desarrollador, a menos que hayas utilizado una herramienta generadora de código, lo que te pondría en el mismo grupo de las personas que meten tenedores en las tomas de luz o toman moringa como único tratamiento contra el cáncer.
Un desarrollador tiene su propia interfaz al proyecto y un medio de interacción con el mismo, que son sus herramientas de codificación y su lenguaje de programación y liberías, respectivamente. Estos deben ofrecer una experiencia positiva igual o mejor que aquella diseñada para el usuario final. Esto es:
- Digerible: la arquitectura de la solución, así como la información de soporte, tiene la estructura adecuada que le permite contextualizarse y ser productivo rápidamente.
- Claridad: los algoritmos, dependencias, estilos y convenciones, son bien entendidas y aplicadas. El código es predecible, explícito y rápido de entender para alguien nuevo en el equipo. La información de errores y casos de excepción es observable y medible.
- Familiaridad: las analogías, vocabulario, tipos implementados (si es un lenguaje serio, no JS), son abstracciones intuitivas y no creaciones arcanas de un líder de proyecto psicótico.
- Confianza y Honestidad: el dominio de aplicación es bien entendido. La comunicación es transparente y pública.
- Deleitable: las tecnologías son interesantes y retadoras. La estrategia de solución es innovadora, pero sensata. El stack de herramientas ofrece una interfaz acogedora y estética, pero sin sacrificar la utilidad.
Si no se atiende a este usuario en primer instancia, el proyecto estará cimentado en sífilis, esto es, eventualmente todos se volverán locos. Alta rotación de personal, fricciones entre los miembros del equipo, problemas con el cliente, y finalmente, la cancelación del proyecto y pérdida irrevocable de recursos.
Antes de hacer el ridículo pagando dinerales por unas sesiones de A/B testing para determinar si el botón debe estar a la izquierda o derecha, dale a tus desarrolladores un IDE con debugger.
