Es nuestra responsabilidad construir aplicaciones altamente intuitivas - Emptor

Aprendí mucho como desarrollador de software en 2010. En ese momento, trabajaba en Ikea implementando proyectos a gran escala, y allí tuve la oportunidad de usar marcos y bibliotecas de los que solo había leído. Todo era nuevo y sorprendente para mí, pero lo más asombroso fue la cultura. La empresa, entre otras cosas, utilizaba un concepto de oficina abierta. Cada departamento estaba compuesto por elegantes y estilizadas mesas para facilitar la comunicación entre departamentos. Mi lugar de trabajo estaba al lado del departamento de TI, estratégicamente posicionado para ayudarnos con el soporte al usuario y, a veces, incluso culparnos por los errores cuando la causa raíz era algún error nuestro.

Una tarde, cuando llegó la hora de volver a casa, después de una llamada urgente de soporte, escuché algo que no esperaba: un miembro del equipo de TI dijo: “No fue un error del sistema, fue un problema de capa 8”. Era la primera vez que escuchaba esa broma, pero curiosamente no me pareció graciosa. Me fui a casa pensando en la gran responsabilidad que tenemos por los errores que los usuarios cometen con nuestros sistemas.

Espera un momento, acabo de decir errores cometidos por los usuarios… aunque “un problema de capa 8” es una broma común, requiere una explicación.
(Nota: Si eres un ninja de sysadmin, salta esta parte 😉)

El modelo de Interconexión de Sistemas Abiertos (modelo OSI) es un modelo de referencia para protocolos de red y tiene como objetivo interconectar sistemas de diferentes fuentes. Se divide en varias capas o niveles:

• Capa física: estructura física (inalámbrica, cable coaxial, repetidores, concentradores)
• Capa de enlace de datos: Tramas (ethernet, switches, puentes)
• Capa de red: Paquetes (IP, IPSec, IGMP)
• Capa de transporte: Conexiones de extremo a extremo (TCP, UDP)
• Capa de sesión: Sincronizar y enviar a puerto (API, Sockets)
• Capa de presentación: Capa de sintaxis (SSL, SSH, FTP)
• Capa de aplicación: Capa de usuario final (HTTP, FTP, IRC)

Has notado que solo hay 7 capas… la 8ª capa que mencionó el tipo de TI era el usuario. Un error en la 8ª capa significa que es culpa del usuario. (Lo sé, podría decir solo esta última parte, pero piénsalo, ahora también sabes sobre el modelo OSI).

Déjame explicarlo de esta manera… digamos que un médico pasa más de 10 años en la universidad para aprender a desempeñar su trabajo; para cuando esté trabajando en un hospital, probablemente se haya perdido la mayor parte de los cambios tecnológicos de una década. Como no tienen mucho tiempo para nada más mientras estudian medicina, ¿cómo podemos esperar que sepan usar tu (mal construida) interfaz de usuario? La misma interfaz que construiste con el mantra: “¡Voy a poner esto en cualquier lugar, no soy diseñador!” Lo sé, no se hizo a propósito; parte del problema es que tendemos a compararnos con el usuario; nos usamos a nosotros mismos como prototipo del usuario. Pero ¿sabes qué? Tú y el usuario están lejos de ser lo mismo.

Parte del problema es que tendemos a compararnos con el usuario; nos usamos a nosotros mismos como prototipo del usuario.

Necesitas tener conversaciones reales o interacciones con tus usuarios reales. No esperes hasta la fase final del proyecto para agregar un poco de UX; eso generalmente no funciona. La UX es muy importante y, a medida que evoluciona la competencia, cada empresa debe trabajar más para construir algo con lo que todos los usuarios puedan interactuar.

Como dije antes, puedes decir: “No soy diseñador, no tengo que ocuparme de eso”. Pero puedes encontrar casos como “El botón de $300 millones”, donde una empresa hizo un cambio en una etiqueta en su sitio web de comercio electrónico y vieron un aumento de $15 millones en los ingresos el primer mes y $300,000,000 adicionales al final del año. Piénsalo, es increíblemente impresionante que un cambio tan “insignificante” pueda tener un impacto tan masivo en los ingresos. Cada caso es diferente. Tal vez te enfoques en reducir el número de llamadas de soporte inclinándote más hacia el autoservicio: por ejemplo, los ingenieros de McAfee diseñaron un proceso que redujo el 90% de las llamadas de los usuarios para obtener soporte. ¿Suena increíble, verdad?

Es nuestra responsabilidad como ingenieros facilitar el viaje del usuario y el cliente.

Todos hemos escuchado a alguien decir: “Oh, mi pequeño hijo es tan inteligente, sabe usar un iPad y solo tiene 3 años”. La verdad del asunto es que algunos ingenieros muy hábiles se esforzaron por construir una interfaz increíblemente amigable para el usuario. Podríamos probarlo dándole a ese mismo niño un viejo Palm Treo para ver cuánto tiempo pasa tratando de usarlo.

Ahora te voy a dar 3 puntos a tener en cuenta cuando se trata de construir aplicaciones.

1. Conviértete en un usuario centrado.
   Deja de tomar decisiones basadas en cosas como el ego, los temas candentes o algo que tu influencer tecnológico favorito acaba de tuitear. Tu decisión debe estar guiada por las necesidades, objetivos, expectativas y motivaciones del usuario, en lugar de las tuyas.

   Cada vez que tengas la oportunidad de construir algo, deberías construirlo pensando en el usuario. La usabilidad es mejor que la belleza, y los usuarios te lo agradecerán cuando descubran cómo usar una nueva función sin pasar demasiado tiempo leyendo instrucciones. Estarán más felices y serán más productivos si pones solo las opciones que puedan necesitar en lugar de todas las que tú, con tus superpoderes, puedas idear.

2. Evita el comportamiento perezoso con la UX.
   Lo sé, tenemos que tener en cuenta varias cosas cuando estamos construyendo, como: interpretar bien los requisitos funcionales, considerar los requisitos no funcionales que no se enumeraron en los requisitos y tal vez también usar algún lenguaje de programación o biblioteca increíble. Todas esas cosas para “Mostrar un número incremental en una etiqueta”. Llevar a cabo todas esas cosas puede consumir demasiada de tu energía, así que cuando se trata de preocuparte por cómo el usuario lo va a usar, tal vez no le estés prestando demasiada atención a eso.

   Deberías usar la autocontención para evitar cometer algunos errores básicos de UX; aquí hay algunos “no hagas”:

   • No arrojes toneladas de datos en la pantalla: no sé a tu usuario, pero probablemente no necesiten toda la base de datos en su pantalla al mismo tiempo.
   • No expongas la tecnología al usuario: incluso como persona técnica que consume una API externa, esperamos recibir un mensaje bien formado para un código de error.
   • No seas inconsistente: si ya decidiste mover el botón de cerrar a la parte inferior de la ventana, asegúrate de que sea lo mismo en todas tus ventanas.

3. Sé consciente de los sesgos cognitivos.
   Los sesgos cognitivos son “errores” que tiene la mente humana. Puedes encontrar una lista muy extensa por ahí y ver cómo pueden afectar la forma en que las personas perciben la realidad. Es muy importante saber que puedes estar afectado por uno de ellos cuando estés creando algo, así que aquí hay algunos comunes a tener en cuenta:

   • Sesgo de ceguera al sesgo es el sesgo cognitivo de reconocer el impacto de los sesgos en el juicio de los demás, mientras se falla en ver el impacto de los sesgos en el propio juicio.
   • Déformation professionnelle (“nerdview”) es la tendencia a mirar las cosas desde el punto de vista de la propia profesión o especialidad, en lugar de desde una perspectiva más amplia o humana.
   • Reflejo de Semmelweis es una metáfora para la tendencia refleja a rechazar nuevas evidencias o nuevos conocimientos porque contradicen las normas, creencias o paradigmas establecidos.
   • El efecto de la ola es un fenómeno por el cual la tasa de adopción de creencias, ideas, modas y tendencias aumenta con respecto a la proporción de otros que ya lo han hecho. A medida que más personas creen en algo, otros también “se suben al carro”, independientemente de la evidencia subyacente.
   • Sesgo de confirmación es la tendencia a buscar, interpretar, favorecer y recordar información que confirma o respalda las creencias o valores previos de uno.

Finalmente, quiero dejarte con el pensamiento de que asumir la responsabilidad de cómo los usuarios van a usar la aplicación que estás construyendo es la forma más justa de pensarlo, porque, al final, eres el profesional en la construcción de software. Piensa un poco en los usuarios sin importar qué tarea estén realizando. Es tu deber ayudarlos con tus aplicaciones en lugar de traerles más problemas.

Cada vez que te encuentres pensando algo como “Piden un formulario, aquí hay un formulario”, recuerda toda la frustración que sientes cuando usas cualquier software horrible en tu vida diaria, tal vez porque no hay otra opción. Piensa que tienes la oportunidad de hacer feliz a alguien; cada vez que usen ese formulario que estás a punto de crear.

Si te gusta este tipo de contenido, no dudes en seguirnos en nuestras cuentas de redes sociales.