Recuperemos el diseño idiomático

 (essays.johnloeber.com)
1 puntos por GN⁺ 17 일 전 | 1 comentarios | Compartir por WhatsApp
  • Los modismos de diseño que los usuarios comprenden de inmediato reducen la carga de aprendizaje y permiten interacciones consistentes
  • En el pasado, durante la era del software de escritorio, las interfaces estaban unificadas gracias al sistema operativo y a sus guías, con estructuras de menús y atajos de teclado consistentes
  • En cambio, en la era del software basado en navegador, la expansión de frameworks e implementaciones personalizadas provocó el colapso de la consistencia en las interfaces
  • Apple y Substack muestran casos exitosos de modismos modernos gracias a una personalización limitada y sistemas de diseño unificados
  • Los diseñadores de producto deben seguir los modismos existentes y priorizar la claridad y la consistencia para avanzar hacia una experiencia de usuario estandarizada en toda la web

Modismos de diseño

  • La casilla de verificación se presenta como un modismo de diseño representativo que los usuarios pueden entender al instante sin aprendizaje adicional
    • Para preguntar si se desea mantener la sesión iniciada, podrían usarse muchas formas de entrada distintas, pero en la práctica siempre se usa una casilla de verificación
    • Esto funciona como un patrón de interacción estandarizado familiar tanto para usuarios como para desarrolladores

Interfaces homogéneas

  • La interfaz es el medio con el que el usuario interactúa con un sistema, y se considera mejor cuanto menos tenga que pensar el usuario
    • Por ejemplo, la función de copiar con el atajo Command+C debería funcionar igual en cualquier lugar
  • Sin embargo, en el entorno actual del software web, la consistencia de las interfaces ha desaparecido
    • Incluso funciones básicas como elegir una fecha o ingresar un número de tarjeta están implementadas de forma distinta en cada sitio
    • Como los atajos y las formas de interacción cambian de una app a otra, el usuario tiene que volver a aprender cada vez “dónde y qué debe pulsar”

La era del software de escritorio

  • El software de escritorio en la época de Windows 95~7 mantuvo una alta consistencia de interfaz
    • La estructura de menús “File, Edit, View” existía de la misma forma en todos los programas
    • Las letras subrayadas en los menús indicaban atajos de teclado, y podían usarse con ALT+F, N, etc.
    • La barra de estado (status bar) en la parte inferior mostraba claramente el estado actual (página, número de palabras, modo, etc.)
    • Se priorizaban los menús basados en texto, y los íconos solo se usaban cuando tenían un significado claro
  • Estos modismos estaban unificados no solo en Microsoft Word, sino en todo el ecosistema de Windows
    • Incluso en la pantalla de cierre de sesión de Windows XP, todos los botones se presentaban visualmente como botones claros, y los atajos aparecían indicados
  • Esta consistencia fue posible gracias a las restricciones del sistema operativo y de las bibliotecas GUI, y Microsoft distribuía cientos de páginas de guías de diseño para incentivar a los desarrolladores a seguirlas

La era del software en navegador

  • La era actual de las aplicaciones web se describe como una era de interfaces heterogéneas
    • Incluso excelentes web apps como Figma y Linear no comparten íconos ni atajos comunes
    • Cada app está bien diseñada por su cuenta, pero tiene patrones de interacción distintos
    • Incluso dentro de una misma empresa, la experiencia entre Gmail, GSuite y Google Docs es diferente
    • Como resultado, el usuario pasa tiempo buscando dónde operar en lugar de mantenerse en un flujo productivo (flow)

  • Impacto de la transición móvil

    • Con la aparición de las pantallas táctiles, los patrones de diseño centrados en mouse y teclado fueron reinventados
    • Al tener que dar soporte a móvil y escritorio al mismo tiempo, proliferaron UI incompletas de forma intermedia
    • Ejemplo: casos en los que el menú hamburguesa pensado para móvil se usa tal cual también en escritorio
    • La cultura de reutilización de componentes modulares replica patrones erróneos y deteriora la calidad
    • Como resultado acumulado de más de 10 años, se produjo una erosión generacional de la calidad UI/UX

  • Falta de modismos más allá del HTML

    • En la web temprana existían modismos claros, como los enlaces azules subrayados, pero hoy el estilo varía de un sitio a otro
    • Los estándares de HTML/CSS son estrictos, pero en la práctica la mayoría usa sistemas de build basados en React y TypeScript
    • Como resultado, proliferan las implementaciones personalizadas en lugar de elementos HTML estándar, lo que además provoca problemas de accesibilidad
    • Ejemplo: usar un <span> con onclick en lugar de un <a>, rompiendo así funciones del lector de pantalla
    • También existen apps como Figma, basadas en WebAssembly, que se apartan por completo del HTML
    • Se ignoran funciones básicas del navegador como el botón de volver, los atajos, etc., y se reconfigura un nuevo paradigma de interacción humano-computadora
    • Como el desarrollo frontend ha evolucionado priorizando la velocidad y las posibilidades, se vuelve difícil establecer modismos consistentes
    • Existen tantos frameworks y formatos de interacción que el entorno hace estructuralmente difícil establecer un único estándar

Casos exitosos de diseño idiomático

  • Apple se menciona como un caso representativo contemporáneo de modismos de diseño sólidos
    • La tipografía, los botones, los colores y el sistema de diseño en general están unificados, y ofrecen una experiencia de interacción consistente en todo iOS
    • Esa consistencia genera la confianza de que “it just works”
  • Substack también ofrece una experiencia de usuario estable gracias a una personalización limitada y a valores estéticos predeterminados
    • Los principios de diseño de Apple y Substack, al demostrar su éxito, se expanden como estándares de la industria y terminan convirtiéndose en nuevos modismos

Principios que deben seguir los diseñadores de producto

  • Se plantea que, siempre que sea posible, para los desarrolladores de producto seguir los modismos de diseño existentes es la vía para mejorar la usabilidad y la compatibilidad
    • Respetar los modismos básicos de HTML/CSS: los enlaces deben implementarse con subrayado, color, cursor tipo puntero y la etiqueta <a>
    • No reimplementar elementos HTML básicos con JavaScript; por ejemplo, usar <button> en lugar de un React Button
    • Respetar los modismos del navegador: que funcione el botón de volver, que al copiar una URL se acceda a la misma interfaz, que CTRL+clic abra una nueva pestaña
    • Si se va a apartar de los modismos generales, mantener al menos reglas consistentes dentro de la organización
    • Texto primero, íconos al mínimo; usar íconos solo cuando sean universalmente comprensibles
    • En los elementos visuales, la claridad debe tener prioridad sobre la belleza estética
    • Cuando sea difícil decidir, consultar casos de buenos sitios web y libros antiguos de diseño de interfaces
  • En última instancia, se propone apuntar hacia un futuro en el que todos los selectores de fecha o formularios de ingreso de tarjetas funcionen igual en toda la web, con el objetivo de una web que, tras décadas de repetición y mejora, converja en los modismos óptimos

Lecturas relacionadas

1 comentarios

 
GN⁺ 17 일 전
Comentarios de Hacker News

  • En algunas apps, Enter envía la entrada y Ctrl+Enter hace salto de línea (por ejemplo, Slack), mientras que en otras es al revés (por ejemplo, GitHub).
    Esta falta de consistencia es bastante confusa desde la perspectiva del usuario. Se dice “revivamos el diseño idiomático”, pero el verdadero problema es que faltan convenciones compartidas

    • Antes, Return y Enter eran teclas distintas. Return era para salto de línea y Enter para enviar la entrada.
      Ahora se fusionaron en una sola tecla, así que por lo general en los campos de entrada multilínea, Enter hace salto de línea y Ctrl+Enter envía.
      En cambio, las apps de chat suelen usarse para mensajes cortos, así que funcionan al revés. Las buenas apps permiten cambiar esto en la configuración
    • Teams tiene dos modos. Por defecto, Enter envía y Shift+Enter hace salto de línea, pero si abres las herramientas de formato, se invierte.
      Aunque te muestra qué combinación hace salto de línea, sigue siendo confuso
    • Slack es todavía más complicado. Si activas Markdown, Shift+Enter hace salto de línea, pero dentro de un bloque de código (```), Enter hace salto de línea y Shift+Enter envía.
      Se entiende la intención, pero la usabilidad es un desastre
    • La solución ideal sería que Ctrl+Enter siempre enviara, Shift+Enter siempre hiciera salto de línea y Enter siguiera el valor predeterminado según el contexto
    • Yo también pensaba que Shift+Enter era salto de línea, y esto muestra que el problema es una UX fragmentada

  • El software de hoy ya no lo hacen diseñadores cuidadosos como antes.
    En su lugar, lo lideran PMs o responsables de producto ascendidos a toda prisa, en una realidad donde incluso se fomentan patrones oscuros para generar ingresos

    • Como ingeniero móvil, cuando les digo a los stakeholders que “no se puede construir solo siguiendo la idea tal cual”, muchas veces me miran con cara de no entender.
      Hay que insistir en la importancia de la consistencia en UX y de la arquitectura de información (IA). Tampoco hay que olvidar que los diseñadores también resuelven problemas
    • Esta crítica es demasiado simplista. En la práctica, hasta crear un simple formulario web es un infierno.
      Por ejemplo, al hacer un formulario de tarjeta de crédito hay muchísimas variables: si se permite copiar/pegar, compatibilidad con navegadores antiguos, equilibrio entre accesibilidad y seguridad, etc.
      Como referencia, el post de Steve Yegge sobre plataformas también explica bien esta complejidad
    • En la década de 2010, muchos UX designers experimentados salieron, y entró en masa gente de impresión o diseño gráfico, diseñadores no especializados, lo que bajó la calidad
    • Claro que hay incentivos perversos y calendarios apretados, pero es difícil verlo solo como incompetencia o mala fe. El sistema en sí cambió
    • Incluso hoy, al ver PMs intentando diseñar por sí mismos toda la arquitectura y hasta el roadmap de lanzamientos, uno siente que esa observación no está equivocada

  • Los frameworks del sistema eran la base que hacía posible una UI idiomática.
    Win32, AppKit y UIKit cubrían hasta los detalles finos, así que los desarrolladores terminaban siguiendo de forma natural una UX consistente.
    En cambio, en la web no existe eso, así que hay que implementarlo todo a mano y, como resultado, abundan las interfaces medio terminadas

    • Pero el autor señala mal la inconsistencia de la web. La “era de escritorio” fue en realidad la era de Windows, y como Win32 era lo predeterminado, todos seguían ese modelo.
      La web fue centrada en documentos desde el inicio y no tuvo un enfoque estándar; más tarde aparecieron cosas como Bootstrap y surgió un estándar temporal
    • HTML y CSS existían, pero hoy se los esquiva con cosas como WebAssembly.
      En realidad, para selectores de fecha o entrada de tarjeta deberían usarse los controles HTML básicos.
      Así el navegador puede ofrecer seguridad y comodidad a nivel del SO (por ejemplo, Safari integra Apple Wallet y Android integra Google Pay)
    • Los desarrolladores acostumbrados al comportamiento consistente del SO intentan naturalmente imitar ese entorno.
      Pero la web y el móvil son entornos de caja cerrada completamente distintos, y esa consistencia se rompió.
      Por ejemplo, hubo una oportunidad de unificar el clic derecho del escritorio con la pulsación larga en móvil, pero nunca se impulsó de manera consistente
    • El problema de fondo de la web es que sigue atada a un paradigma centrado en documentos.
      Para construir una UI de app hay que montarla encima de una UI documental, y eso genera conflictos.
      Los navegadores han mitigado esto, pero no es una mejora de raíz
    • Como dato, en AppKit también se puede cambiar la altura de los botones. Solo que no es obvio

  • Los selectores de fecha son realmente una pesadilla de UX.
    Muchas veces bloquean al usuario cuando intenta escribir la fecha manualmente y lo obligan a hacer clic sí o sí.
    Bastaría con validar errores de entrada, pero igual lo vuelven incómodo

    • Cuando tienes que pasar por décadas enteras del calendario para poner tu fecha de nacimiento, sientes la fugacidad de la vida
    • Los selectores de hora en móvil también son inconsistentes. A veces un solo scroll te lleva de 12:00 a 11:50, y a veces no.
      Un selector tipo reloj analógico parece más intuitivo; ojalá algo así se volviera el estándar
    • El formato de fecha también es un problema. 03/04/2026 puede ser 4 de marzo o 3 de abril.
      Para usuarios internacionales, el formato YYYY-MM-DD es más seguro
    • Los sitios que usan el mismo selector de fecha para fecha de nacimiento y para eventos futuros son de lo peor.
      Te obligan a scrollear 50 años hacia atrás y de paso te hacen sentir tu edad
    • Tener que sentir tu edad cada vez que ingresas tu fecha de nacimiento haciendo scroll parece una forma de tortura

  • Últimamente la calidad de la UX ha caído muchísimo, y se nota especialmente en los sitios web bancarios.
    Ocultan las barras de desplazamiento, desperdician espacio en blanco, usan botones planos e íconos confusos, y terminan siendo mucho más incómodos que las viejas interfaces de escritorio

    • De verdad no se entiende por qué ocultan las barras de desplazamiento. Parece una decisión puramente estética para que “se vea bonito”
    • Siento que Material UI perjudicó a varias industrias.
      GCP y otras herramientas de Google se volvieron innecesariamente complejas y arruinaron la UX con cosas como campos de entrada sin borde.
      Por suerte, hoy ese estilo ya empieza a verse anticuado

  • Un concepto de los viejos Mac era que, si el texto de un botón terminaba en puntos suspensivos (…), significaba que haría falta información adicional.
    En cambio, un botón sin puntos suspensivos completaba la acción inmediatamente al hacer clic

  • Coincido con la idea de “preferir palabras antes que íconos”.
    Para la mayoría de la gente, la velocidad de reconocimiento de palabras es mayor que la de íconos

    • Claro, los íconos que representan objetos reales pueden funcionar, pero hoy abundan demasiado los íconos abstractos y lineales.
      Sin texto explicativo, tienes que hacer clic para descubrir su significado, como si fuera ruleta rusa
    • También hay casos confusos como “unvote/undown” en HN, donde comparten el mismo prefijo y se vuelven fáciles de confundir. Terminas revisándolo cada vez antes de hacer clic
    • Si los íconos son pequeños o cambian mucho de posición, las palabras son mejores; pero en entornos fijos, los íconos pueden llegar a ser más rápidos

  • Hace poco descubrí una nueva tecnología llamada CSS, que permite definir layouts de forma declarativa y aplicar estilos jerárquicos basados en el DOM.
    Reduce la carga del cliente y del servidor, y facilita compartir hojas de estilo o crear temas personalizados para usuarios.
    Me gustaría llamarlo el paradigma de UI “no-framework”
    Imagen de ejemplo

    • Lo probé y fue una pesadilla total. No hay forma de saber qué estilo se aplica dónde, y si cambia la estructura del DOM, los estilos quedan hechos un desastre.
      Además, eso de “minimizar la carga del cliente” no es más que un mito. En la práctica es más lento
    • Tal vez sería buena idea proponerle esta idea al equipo del framework vanilla-js

  • Funciones comunes que perdimos:
    Undo/Redo, ayuda (F1), pistas al pasar el mouse, personalización de atajos, menú principal, archivos/directorios, cerrar con ESC, arrastrar y soltar, etc.
    Funciones que alguna vez fueron innovadoras ahora casi desaparecieron en móvil y web

  • Muchos problemas son resultado de que diseñadores visuales pasaron a diseñar productos.
    La confusión entre roles dentro del área de diseño sigue sin resolverse y, en realidad, se mete a demasiados “diseñadores” incluso en proyectos que no los necesitan