KomuraSoft LLC
Contáctenos
Menú

Diseño de UX para apps de Windows: prioridades según el entorno de uso

· Actualizado el: · · UX, Desarrollo en Windows, Diseño de UI, Accesibilidad, Aplicaciones empresariales

Cuando se piensa en la UX de una app de Windows, si se empieza por «¿se ve moderna?» o «¿los espacios en blanco quedan bien?», es fácil equivocarse de orden.

En el escritorio de Windows, la UX no se decide solo por el aspecto visual.

  • Hasta dónde se puede completar todo con el teclado
  • Si se asume el mouse o la pantalla táctil
  • Si se usa durante mucho tiempo o solo unos minutos de vez en cuando
  • Si es monitoreo, entrada de datos o un terminal de campo
  • Qué se rompe cuando se comete un error
  • Si resiste la ampliación de texto, los temas de contraste y la tecnología de asistencia

Todo esto junto es la UX.

Y lo que complica aún más las cosas es que el centro de gravedad es distinto entre ToC y ToB. Sin embargo, si aquí se piensa «como es ToB, basta con llenarlo de información» o «como es ToC, basta con hacerlo ligero y desenfadado», casi siempre se termina en un accidente en algún punto.

Por ejemplo, incluso dentro del mismo ToB tenemos:

  • Apps administrativas como la entrada contable o la gestión de pedidos
  • Terminales de campo como fábricas, almacenes, recepciones o equipos de inspección
  • Pantallas de operación de monitoreo 24 horas o soporte de mantenimiento

y las condiciones para una buena UX cambian bastante entre ellas.

Y a la inversa, dentro de ToC tenemos:

  • Pequeñas utilidades para uso personal
  • Herramientas más bien avanzadas como edición de imágenes, producción musical o análisis de inversiones

donde la densidad de la UI y la necesidad de atajos son completamente distintas.

Las guías de diseño de Microsoft para Windows también dan importancia a que el diseño de una app de Windows sea intuitivo, accesible y que funcione de forma consistente entre distintos métodos de entrada y factores de forma.12

En este artículo organizamos la UX de las apps de Windows como una tabla de decisión por tipo de uso. El objetivo es facilitar, en revisiones de diseño o en las etapas iniciales del diseño de pantallas, la tarea de separar «qué debería priorizar esta app».

Público objetivo y supuestos de este artículo

Elemento Contenido
Público objetivo Personas que deciden el diseño de pantallas de una app de escritorio de Windows. No importa si son desarrolladores, diseñadores o personal de planificación
Quién debe decidir La tabla de decisión del capítulo 3 y las 8 preguntas del capítulo 9 están pensadas para que puedan completarse solo con el equipo de desarrollo. Si hay un diseñador separado, entregarle antes las respuestas del capítulo 9 como base compartida reduce el retrabajo
Conocimientos que se dan por sentados No se presupone conocimiento de un framework específico como WinForms, WPF o WinUI
Lo que no se trata El diseño visual, como la paleta de colores o la tipografía, ni la implementación de controles individuales

Terminología usada en este artículo

Término Significado en una línea
Drill-down (profundización) Operación de elegir un elemento de una lista y seguir explorando su contenido
Flyout (panel emergente) Panel pequeño y temporal que se abre de forma ligera desde un botón o icono. A diferencia de un diálogo, no bloquea toda la pantalla
Occlusion (oclusión) En operaciones táctiles, el hecho de que el dedo o la mano que presiona oculte parte de la pantalla
Migas de pan Fila de enlaces que permite recorrer, de nivel superior a inferior, la jerarquía hasta la ubicación actual
Zona de impacto (hit area) Rango que realmente se puede presionar. No siempre coincide con el tamaño visible del icono
Tecla de acceso Tecla que, combinada con Alt, permite ir directamente a un menú o botón
Tema de contraste Modo de visualización de alto contraste, con una paleta de colores reducida, que se activa desde la configuración de Windows
UIA UI Automation. Mecanismo mediante el cual la tecnología de asistencia lee la estructura y los elementos de una app
epx Effective pixel. Unidad lógica de píxel, ya independiente del factor de escala de la pantalla

1. Conclusión, antes que nada

Dicho de forma resumida, es así:

  • En ToC, priorice primero la facilidad de comprensión en el primer uso, la sensación de seguridad, pocos ajustes de configuración y un flujo directo
  • En ToB, priorice primero la eficiencia continua, la prevención de errores de operación, el soporte de teclado y una disposición estable
  • Sin embargo, en los terminales de campo de ToB, lo prioritario no es la densidad sino la claridad, objetivos de operación grandes y rutas cortas
  • Sin embargo, en las herramientas para expertos de ToC, lo prioritario no es la simplicidad sino la densidad de información, los atajos y la personalización
  • En apps de Windows, conviene pensar la UX incluyendo teclado, mouse, pantalla táctil, ampliación de texto, temas de contraste y tecnología de asistencia; así el diseño es menos propenso a romperse más adelante134567

Lo primero que realmente hay que decidir no es solo si es ToC o ToB. Conviene poner en palabras, antes que nada, estas 5 preguntas:

  1. Quién la usa (principiante, experto, o una mezcla)
  2. Dónde se usa (escritorio, sala de reuniones, campo, fábrica, recepción, exteriores)
  3. Con qué se opera (teclado, mouse, pantalla táctil, lápiz óptico, código de barras, tecnología de asistencia)
  4. Con qué frecuencia se usa (sobre todo la primera vez, de vez en cuando, a diario, todo el día)
  5. Cuál es el costo de un error (leve, grave, peligroso, sujeto a auditoría)

Una vez claras estas 5 preguntas, resulta mucho más fácil decidir las prioridades de la densidad de la UI, la navegación, los atajos, los cuadros de diálogo de confirmación y la personalización.

2. ToC / ToB es el punto de partida, no la respuesta

La distinción entre ToC y ToB es práctica como primer punto de partida. Sin embargo, lo que determina con más fuerza la respuesta correcta de UX no es el tipo de comprador, sino el tipo de uso.

Por ejemplo, si lo miramos a grandes rasgos con 2 ejes, queda algo así:

  Prioridad en el primer contacto Prioridad en la eficiencia continua
ToC Utilidades personales, apps de configuración, herramientas de sincronización Edición de imágenes, producción musical, análisis de inversiones, herramientas de soporte al desarrollo
ToB Terminales de recepción, terminales de almacén, terminales de inspección, quioscos Entrada contable, pedidos, monitoreo, análisis, operación de soporte

Es decir, no es cierto que:

  • ToC = siempre una UI ligera
  • ToB = siempre una UI de alta densidad

Las guías de diseño de apps de Windows también dan importancia a poder usarse de forma consistente entre dispositivos, tipos de entrada y factores de forma, y desde el punto de vista de la accesibilidad se considera importante pensar no solo en la presencia o ausencia de una discapacidad, sino también en restricciones del entorno como exteriores muy iluminados, espacios compartidos, lugares silenciosos o lugares ruidosos.12

Por eso, después de mirar ToC / ToB, se recomienda seguir cortando por este otro eje:

Eje Cuanto más se orienta al primer contacto Cuanto más se orienta a la eficiencia continua
Costo de aprendizaje Prioriza poder usarse sin explicación Tolera cierto grado de aprendizaje
Densidad de información Poca, acotada Mucha, prioriza ver todo de un vistazo
Operación con teclado Auxiliar Bastante importante
Personalización Poca, o bien optimización automática Se quiere ajustar columnas, visualización, disposición y atajos
Prevención de errores de operación Sensación de seguridad, fácil de deshacer Prevención de accidentes, auditoría, confirmación, control de permisos
Transición de pantallas Directa y poco profunda Puede ser densa si prioriza la eficiencia del trabajo

Al cortar primero por aquí, se reducen bastante las discusiones de reunión del tipo «como que se ve moderno» o «como que parece de negocios».

3. Tabla de decisión por uso, de un vistazo

Primero colocamos la tabla más práctica para el trabajo diario.

Uso Usuario típico Lo primero a priorizar UI / navegación adecuada Qué evitar Más detalles
Utilidad para ToC / app personal Usuario en primer contacto, uso de frecuencia baja a media Poder empezar sin perderse, sensación de seguridad, pocos ajustes Pantalla única, navegación superior, flujo poco profundo Exceso de información, exceso de jerga técnica, jungla de pantallas de configuración 4.1
ToB de entrada de datos administrativos y back office Personal administrativo, de soporte u operadores que usan la app a diario Eficiencia continua, completar todo con el teclado, prevención de errores de entrada Navegación lateral izquierda, lista/detalle, lista + detalle, atajos UI de tarjetas con exceso de espacio en blanco, operaciones ocultas, confirmación modal en cada acción 4.2
ToB de monitoreo y operación Personal de mantenimiento, de monitoreo, de guardia No pasar por alto una anomalía, entender la transición de estados, operación segura Panel + drill-down, navegación lateral izquierda, cronología/registros Comunicar el estado solo con color, efectos vistosos, que una operación peligrosa se vea liviana 4.3
ToB de terminales de campo, UI de equipos y quioscos Trabajo de pie, con guantes, con prisa, usuarios sin perfil técnico Legibilidad, objetivos de operación grandes, rutas cortas, resistencia a errores Pantalla de una sola función orientada al tacto, tipo asistente, indicación de estado clara Botones pequeños, dependencia del hover, menús profundos, exceso de entrada libre 4.4
Herramienta de edición y análisis para expertos Usuario experimentado, uso prolongado Densidad de información, atajos, personalización, continuidad del trabajo Pestañas, múltiples paneles, navegación lateral izquierda, menú contextual Ocultar demasiado pensando en principiantes, enterrar funciones en capas profundas 4.5
Herramienta residente / app de bandeja Usuario que la toca poco tiempo y de vez en cuando, uso en segundo plano Poder abrirla enseguida, no estorbar, que se entienda el estado de fondo Menú de bandeja, panel emergente, pantalla principal mínima Mostrarse siempre en primer plano, ráfaga de notificaciones, robar la pantalla principal por cosas triviales 4.6

Con solo esta tabla ya se ve más o menos la dirección a seguir. Lo más importante es que incluso en ToB, un terminal de campo no acierta con una UI de alta densidad, y que incluso en ToC, en herramientas avanzadas la eficiencia es más importante que la ligereza.

Si tiene prisa, puede detenerse en este capítulo. El siguiente capítulo 4 desarrolla cada fila de esta tabla en «por qué es así» y «qué colocar en concreto». No repite las mismas conclusiones de la tabla; permite leer solo el material de decisión que no cupo en ella.

4. Lineamientos de diseño por uso

4.1 Utilidades para ToC / aplicaciones personales

En una pequeña app de Windows para ToC, lo más fuerte de todo es, ante todo, «poder usarla de inmediato al abrirla».

Lo que conviene priorizar especialmente es esto:

  • Que en la primera pantalla se entienda para qué sirve la app
  • Que las operaciones principales se limiten a una o dos
  • Que el estado vacío no resulte poco amigable
  • Que las operaciones peligrosas se puedan deshacer
  • No mostrar todos los elementos de configuración desde el inicio

Aquí es fácil caer en la tentación de mostrar todo lo que técnicamente se puede hacer. Pero en una herramienta ligera de ToC, en muchos casos poder usarla de inmediato vale más que tener muchas funciones.

Tampoco en el diseño de navegación de Windows existe una única respuesta correcta común a todas las apps; se prioriza primero la consistencia, la simplicidad y la claridad. Usar controles estándar y ubicaciones habituales hace que la app resulte más predecible.8

Por eso, en apps para ToC, suele bastar con este tipo de organización:

  • Si es pequeña, pantalla única
  • Si las secciones son paralelas, navegación superior
  • Mostrar la configuración de forma progresiva
  • Que la acción principal destaque y el resto sea discreto

Sin embargo, incluso dentro de ToC, cuando se trata de apps avanzadas como edición de fotos, edición de video, composición musical, análisis de inversiones o soporte al desarrollo, la historia cambia. En ese caso, en lugar de la etiqueta ToC, conviene mirar el nivel de experiencia y el tiempo de uso para acercarse más a la respuesta correcta.

4.2 ToB de entrada de datos administrativos y back office

En una app administrativa de ToB, lo importante no es la ligereza visual sino que el trabajo no se detenga.

El usuario que la usa a diario se acostumbra a la UI en pocos días. Después de eso, lo que empieza a pesar es esto:

  • Hasta dónde se puede llegar solo con el teclado
  • Si es fácil ir y volver entre la lista y el detalle
  • Si las columnas o estados importantes se ven de un vistazo
  • Si se pueden conservar los filtros y el orden
  • Si los errores se pueden corregir en el momento

En la guía de accesibilidad de teclado de Microsoft también se considera importante que la app pueda alcanzar todas sus funciones con el teclado, recomendándose el orden de tabulación, el foco, la operación con Enter/Espacio y la implementación de atajos.3

Además, las teclas de acceso no solo son útiles para la accesibilidad, sino también para mejorar la eficiencia de usuarios avanzados que prefieren el teclado. Se recomienda dar soporte a las teclas de acceso, incluso en controles personalizados, allí donde sea pertinente.9

En sistemas de entrada de datos administrativos, lista/detalle es una navegación sólida. La guía de navegación de Windows también indica que lista/detalle es adecuado para cambiar de elemento con frecuencia mientras se muestra o actualiza el detalle, y que resulta apropiado en casos como la bandeja de entrada de correo, una lista de contactos o la entrada de datos.8

Es decir, una estructura directa suele ser algo así:

  • A la izquierda, la clasificación de funciones
  • En el centro, la lista
  • A la derecha o abajo, el detalle / edición
  • Arriba, la búsqueda, los filtros y los comandos principales
  • Las operaciones frecuentes con soporte de atajos

En sentido contrario, también vale la pena mencionar los patrones que conviene evitar:

  • Un cuadro de diálogo por cada operación
  • Demasiadas pocas columnas, con poca capacidad de ver todo de un vistazo
  • Que la operación principal solo esté en el fondo de un clic derecho
  • Intentar transmitir el significado solo con iconos
  • Un orden de tabulación desordenado, donde ni Enter ni Espacio funcionan

En cuanto a los errores de entrada, también resulta más natural que los errores de validación ligados a un campo se muestren dentro de la pantalla y no en un diálogo. La guía de cuadros de diálogo de Windows también recomienda, para casos como el campo de contraseña, no usar un diálogo para errores de validación ligados al contexto, sino usar una indicación en línea.10

4.3 ToB de monitoreo y operación

En la UX de una pantalla de monitoreo y operación, antes que «ser fácil de usar», lo importante es no pasar nada por alto, no equivocarse y no detenerse.

Aquí, el orden de prioridad suele quedar más o menos así:

  • Que se vea de un vistazo si hay una anomalía
  • Que se entienda la gravedad de la anomalía
  • Poder seguir no solo el valor actual sino también los cambios y la línea de tiempo
  • Que la ruta hacia una operación peligrosa no sea demasiado liviana
  • Poder ir enseguida a registros, historial e investigación de causas

En este tipo de pantalla, la representación del estado es el centro de la UX. Conviene expresar el estado con varios elementos combinados: color + texto + icono + hora, en la medida de lo posible. Cuando el estado se comunica solo con color, aumentan los descuidos y los errores de identificación, y también se debilita desde el punto de vista de la accesibilidad.11

En cuanto a la navegación, resulta manejable organizarla así: si hay muchos objetos de monitoreo, navegación lateral izquierda; para profundizar en un objeto en particular, drill-down; y para el detalle, mostrar registros o cronología. La guía de navegación de Windows también indica que la navegación lateral izquierda es adecuada cuando hay muchos elementos de nivel superior y en estructuras donde no se cambia de página constantemente.8

En cuanto a la operación, es peligroso también colocar el comando en un solo lugar. La guía de diseño de comandos de Windows recomienda que los comandos puedan usarse desde varias superficies, como botones, menús contextuales, atajos o gestos, y que todos los comandos relacionados se incluyan en el menú contextual o en un CommandBarFlyout. Depender de una operación que solo aparece con el hover hace que deje de poder usarse en un dispositivo táctil o con tecnología de asistencia.1213

El cuadro de diálogo de confirmación para operaciones peligrosas también es importante aquí. Sin embargo, «confirmar de todo por si acaso» resulta contraproducente. Lo que realmente conviene confirmar son las operaciones más bien irreversibles: detener, eliminar, cambiar, bloquear o sobrescribir. Si se muestra un diálogo, conviene respetar al menos estas 3 reglas:

  • Escribir con claridad, en la primera línea, qué va a ocurrir
  • Que el texto del botón sea concreto, como Eliminar / Detener / Bloquear, en lugar de Aceptar / Sí
  • Incluir siempre un botón del lado seguro

10

4.4 ToB de terminales de campo, UI de equipos y quioscos

El terminal de campo es una categoría bastante distinta incluso dentro de la UX de las apps de Windows.

Son condiciones habituales:

  • No está sentado
  • Puede que lleve guantes puestos
  • Tiene solo una mano libre
  • No mira la pantalla con detenimiento
  • Hay presión de tiempo
  • Se usa en un lugar muy iluminado o ruidoso

La guía de accesibilidad de Microsoft también indica que una buena app de Windows debe considerar restricciones del entorno que van más allá de la presencia o ausencia de una discapacidad, incluyendo situaciones como luz solar intensa, espacios compartidos, ruido, silencio o estar cocinando.2

Además, en el diseño táctil existen diferencias como:

  • El tacto no tiene hover
  • El dedo o la mano ocultan parte de la UI (occlusion)
  • Parte de la pantalla puede ser difícil de presionar por la postura de la mano
  • La retroalimentación visual es importante

4

Por eso, en un terminal de campo, en general conviene orientarse en esta dirección:

  • Que los botones y elementos de lista sean suficientemente grandes
  • Acercarse a una pantalla, un propósito
  • Mostrar con claridad la reacción después de la operación
  • Dividir el flujo en pasos
  • Preferir, en la medida de lo posible, la selección, el escaneo o los formatos predefinidos frente a la entrada libre
  • Mostrar el estado con claridad en la parte superior o central de la pantalla

En sentido contrario, conviene evitar:

  • Texto pequeño
  • Zonas de impacto pequeñas
  • Dependencia de la información sobre herramientas (tooltip) que presupone hover
  • Jerarquías profundas
  • Gran cantidad de información en una sola pantalla
  • Entrada libre extensa

La idea simplista de «como es ToB, mejor cuanto más densa sea» es donde más fácil se falla en este terreno. Aquí, más bien, es el mundo donde la claridad es la prioridad, incluso dentro de las apps empresariales.

4.5 Herramientas de edición y análisis para expertos

En herramientas para expertos, a veces gana más «no me detengas» que «hazlo más fácil de entender».

Por ejemplo:

  • CAD
  • Análisis de formas de onda
  • Edición de video
  • Procesamiento de imágenes
  • Producción musical
  • Soporte al desarrollo
  • Análisis de datos
  • Herramientas de auditoría / diagnóstico

En este tipo de app, funcionan bien elementos como estos:

  • Densidad de información
  • Múltiples paneles
  • Pestañas
  • Menú contextual
  • Atajos
  • Guardar la disposición
  • Personalización de columnas y elementos mostrados
  • Deshacer / Rehacer
  • Restauración del estado de trabajo

La guía de navegación de Windows también indica que las pestañas son adecuadas para casos donde se quiere abrir, cerrar y reordenar varias páginas o documentos.8 Además, en el diseño de comandos de Windows se recomienda que los comandos se compartan en varias superficies de la UI, de modo que aunque cambie el método de entrada se pueda llegar a la misma operación.12

En este tipo de herramienta, algo que suele suceder es que, por intentar ser amigable con los principiantes, se oculta todo en menús profundos. Pero un usuario experimentado repite la misma operación cientos de veces al día. Para esas personas, lo importante no es la facilidad de los primeros 5 minutos, sino que no se sientan cansadas incluso después de 100 horas de uso.

Por eso, para usuarios avanzados suele funcionar un diseño así:

  • Las operaciones de alta frecuencia, cerca
  • Las funciones auxiliares, un poco más al fondo
  • Las funciones avanzadas, organizadas pero sin desaparecer
  • Guardar la disposición de la pantalla
  • Reforzar la operación con teclado

4.6 Herramientas residentes y apps de bandeja

En las apps residentes, no hacer notar demasiado su presencia es, en sí mismo, la UX.

Por ejemplo, en apps como:

  • Estado de sincronización
  • Estado de conexión
  • Copia de seguridad
  • Cambio de audio / cámara / dispositivo
  • VPN / agente / lanzador
  • Centro de notificaciones

en muchos casos la pantalla principal no es la protagonista.

Conviene priorizar:

  • Poder acceder de inmediato desde la bandeja o un menú pequeño
  • Que se entienda el estado actual
  • Notificar solo cuando es necesario
  • Poder ir directamente desde la notificación a la operación necesaria
  • Que la pantalla principal no acapare el primer plano en exceso

Conviene evitar:

  • Mostrar un diálogo por cosas triviales
  • Abrir la pantalla principal cada vez que se inicia
  • Que no se vea el estado de la operación en segundo plano
  • Demasiadas notificaciones, hasta el punto de que se ignoren todas

En este tipo de app, más que «tener muchas funciones», lo que suele decidir la UX es no estorbar.

5. Tabla de decisión de navegación

La guía de navegación de Windows establece que no existe un único diseño de navegación que funcione para todas las apps, y que los principios son la consistencia, la simplicidad y la claridad. Además, colocar los controles estándar en el lugar que el usuario espera hace que la UI sea más predecible.8

En la práctica, resulta más fácil de manejar si se corta según esta tabla:

Patrón Situación adecuada Uso típico Puntos de atención
Pantalla única + filtro El propósito principal es uno solo y hay pocas funciones Herramienta pequeña de ToC, herramienta de conversión, ayuda de configuración No amontonar todo en una sola pantalla
Navegación superior Páginas del mismo nivel en paralelo, que se quieren mostrar todas App de ToC, pantalla de configuración de tamaño pequeño a mediano Si aumentan demasiado los elementos, se pierde la visión de conjunto
Navegación lateral izquierda Muchos elementos de nivel superior, grupos de funciones bien definidos Pantalla de administración ToB, monitoreo, consola de gestión Apoyar las jerarquías profundas con migas de pan o encabezados
Lista/detalle Se cambia de elemento con frecuencia mientras se ve o se actualiza el detalle Bandeja de entrada, lista de clientes, lista de comprobantes, entrada de datos Dejar claro el estado de selección y el estado de edición
Pestañas Se quieren abrir a la vez varios documentos u objetos de trabajo Editor, herramienta de análisis, pantalla de comparación No forzar todas las funciones a convertirse en pestañas
Migas de pan Jerarquía profunda, es fácil perder de vista la ubicación actual Datos jerárquicos, árbol de clasificación, gestión de archivos Es útil cuando se supera una profundidad de 2 niveles

La guía de navegación de Windows muestra en particular esta forma de distribución de usos:8

  • Navegación superior: cuando se quieren mostrar en pantalla todos los elementos de navegación
  • Navegación lateral izquierda: cuando hay muchos elementos de nivel superior y no se cambia de página con frecuencia
  • Lista/detalle: cuando se cambia de elemento con frecuencia y se necesita ver o actualizar el detalle
  • Pestañas: cuando se quieren abrir y cerrar dinámicamente varios documentos o páginas
  • Migas de pan: cuando la jerarquía es profunda y se quiere dejar claro el camino de regreso

5.1 Wireframes con solo el esqueleto

Solo con palabras cuesta formarse una imagen, así que aquí colocamos 4 esqueletos representativos. Ignore los detalles y fíjese únicamente en qué se coloca dónde.

[ Navegación superior ]  Cuando se quieren mostrar todas las páginas del mismo nivel
+-------------------------------------------------------------
| NombreApp      Inicio | Conversión | Historial | Configuración
+-------------------------------------------------------------
|
|    Contenido principal
|    Acercarse a una pantalla, un propósito
|
+-------------------------------------------------------------


[ Navegación lateral izquierda ]  Cuando hay muchos elementos de nivel superior
+-------------------------------------------------------------
| NombreApp                                Buscar [          ]
+-------------------------------------------------------------
| Panel            |
| Lista de equipos |    Contenido principal
| Alertas          |
| Trabajos         |
| Informes         |
| Configuración    |
+-------------------------------------------------------------


[ Lista/detalle ]  Cambiar de elemento mientras se ve y se actualiza el detalle
+-------------------------------------------------------------
| Buscar [         ]  Filtro: Pendientes / Todos     [Nuevo] [Eliminar]
+-------------------------------------------------------------
| Lista            |  Detalle / edición
|  > Comprobante 1001 |    N.° de comprobante  1001
|    Comprobante 1002 |    Cliente             ...
|    Comprobante 1003 |    Líneas de detalle   ...
|    Comprobante 1004 |
|                  |    [ Guardar ]   [ Cancelar ]
+-------------------------------------------------------------


[ Panel + drill-down ]  Encontrar una anomalía y profundizar en ella
+-------------------------------------------------------------
| General   Normal 22   Atención 3   Anomalía 1     Actualizado hace 0.5 s
+-------------------------------------------------------------
| 1 anomalía
|   ! Equipo de inspección Línea B    Sin respuesta   hace 48 s   [ Detalle ]
| 3 en atención
|   - Cámara Línea A       Valor desactualizado  hace 12 s   [ Detalle ]
|   ...
+-------------------------------------------------------------
              |
              |  Presionar [ Detalle ]
              v
+-------------------------------------------------------------
| < Volver a la lista    Equipo de inspección Línea B / Sin respuesta
+-------------------------------------------------------------
| Valor actual | Gráfico de línea de tiempo | Registro de eventos | Operación
+-------------------------------------------------------------

Al colocar los 4 juntos, el criterio de elección queda claro.

  • La diferencia entre navegación superior y navegación lateral izquierda está en la cantidad de elementos de nivel superior. Si todos caben en fila horizontal, superior; si no caben, lateral izquierda
  • El protagonista de lista/detalle no es el lado derecho, sino la lista del lado izquierdo. Si la cantidad de información de la lista no es suficiente, se termina abriendo el detalle una y otra vez
  • El punto clave del panel es mostrar en la primera línea «cuántas anomalías hay». Al ir a profundizar, siempre hay que preparar un camino de regreso

En resumen, la navegación no es «un gusto visual», sino un reflejo de la estructura de la información y del trabajo.

6. Tabla de decisión de dispositivos de entrada y diseño de comandos

Una app de Windows resulta más flexible y fácil de usar cuanto más métodos de entrada admite. Las guías de Microsoft también recomiendan considerar tantos métodos de entrada como sea posible, como gestos, voz, tacto, panel táctil, mouse y teclado.14

Además, dado que los controles de la plataforma de Windows ya absorben en cierta medida varios métodos de entrada, usar los controles estándar sin modificar es de entrada una opción sólida.48

Si lo llevamos a una forma práctica para el trabajo diario, queda así:

Supuesto Operación a priorizar Cómo diseñarlo Qué evitar
Teclado + mouse como principal Tab, Enter, Espacio, atajos, clic derecho Aumentar la capacidad de ver de un vistazo, dar soporte de atajos a las operaciones principales, reforzar también el clic derecho Operaciones que solo se pueden presionar con el mouse, operaciones que dependen solo de iconos pequeños
Tacto como principal Objetivos grandes, operación directa, retroalimentación visible No depender del hover, mostrar con claridad el cambio de estado, acortar el flujo Botones pequeños, dependencia del hover, operaciones detalladas ubicadas en el borde
Entorno mixto Preparar varias rutas hacia el mismo comando Usar juntos la barra de herramientas, el menú contextual y los atajos Una operación importante que solo exista en un método de entrada
Con controles personalizados Foco, atributos de accesibilidad, soporte de tecnología de asistencia Envolver con un control estándar, verificar UIA, agregar visualización del foco Colocar directamente una imagen que se puede pulsar, sin foco

En torno al teclado, lo especialmente importante es lo siguiente:39

  • Que se pueda llegar a todas las funciones solo con el teclado
  • Que el orden de tabulación no esté muy desviado del orden visual
  • Que los elementos que deberían poder presionarse con Enter/Espacio realmente lo permitan
  • Que las funciones importantes tengan un atajo
  • Preparar teclas de acceso o aceleradores para las operaciones de alta frecuencia

En torno al tacto, existen características como estas:4

  • No hay hover
  • El dedo o la mano ocultan la UI
  • El lugar que se puede presionar se siente más estrecho de lo que parece
  • Se necesita retroalimentación visual
  • La UI adecuada para operación directa y la adecuada para entrada indirecta son distintas

6.1 Decidir con números, no con «suficientemente grande»

En las revisiones de diseño, es fácil trabarse en cosas como quedarse en «suficientemente grande» o «que se note claramente». En los puntos donde la guía de Microsoft ofrece un número, conviene usar ese número directamente como criterio de aprobación o rechazo; así la discusión se acorta.

Qué se quiere decidir Número Nota adicional
Tamaño del objetivo táctil Tomar como referencia 7,5 mm de lado. En una pantalla de 135 PPI con escala 1,0, esto equivale a 40 x 40 píxeles15 Lo que se presiona con frecuencia o cuyo error de operación tiene mucho impacto debe superar este mínimo, ampliando también el margen alrededor15
Relación de contraste del texto visible 4,5:1 como mínimo5 Se ve en conjunto con el tema de 8.4 de no comunicar el estado solo con color
Espacio entre botones, entre un control y un encabezado 8epx16 Es la distancia para cuando se quiere mostrar que pertenecen al «mismo grupo»
Espacio entre un control y su etiqueta, entre áreas de contenido 12epx16 Es la distancia para cuando se quiere mostrar que son «agrupaciones distintas»
Espacio entre el borde de una superficie y el texto 16epx16 Si se reduce aquí, es lo primero que se rompe al ampliar el texto

Cuando el número está definido, también cambia la forma de expresarlo en la revisión. En vez de «¿no le parece que este botón es pequeño?», poder decir «este botón mide 32px, así que no llega al mínimo de 7,5 mm» permite cerrar en el momento la discusión sobre si corregirlo o no.

Cabe señalar que los controles estándar de WinUI ya están construidos por defecto para respetar este tamaño de objetivo.15 Dicho de otro modo, el peligro se concentra justamente en los controles propios y en el dibujo personalizado.

En el diseño de comandos, la guía de comandos de Windows es una buena referencia. Lo especialmente importante es poder usar el comando desde varias superficies de la UI.12

  • Se puede presionar desde un botón
  • También está en el menú contextual
  • También se puede invocar con un atajo
  • Si hace falta, también admite deslizar o gestos

Y se recomienda incluir todos los comandos relacionados en el menú contextual o en un CommandBarFlyout. Depender de una operación que solo se ve mientras se hace hover se traba en un dispositivo exclusivamente táctil.12

7. Elementos de UX que no se deben pasar por alto en una app de Windows

A partir de aquí resumimos, sin importar el uso, lo mínimo que conviene tener en cuenta.

7.1 ¿Se puede completar todo con el teclado?

En el escritorio de Windows, el teclado no es algo del tipo «viene bien tenerlo», sino un medio de entrada principal.

La guía de accesibilidad de teclado de Microsoft también indica que el soporte de teclado es importante no solo para usuarios con limitaciones visuales o motrices, sino también para usuarios que eligen el teclado por eficiencia.3

Como mínimo conviene revisar estos 5 puntos:

  • ¿El orden de tabulación es natural?
  • ¿Existe visualización del foco?
  • ¿Se puede presionar con Enter/Espacio?
  • ¿Existen atajos?
  • ¿Se puede invocar con el teclado el equivalente a un clic derecho?

Es un detalle discreto, pero cuando esto falla, la UX de ToB sufre bastante.

7.2 Ampliación de texto, temas de contraste y accesibilidad

En una app de Windows, con solo seguir correctamente el tamaño de texto y el contraste, la UX se estabiliza mucho.

La guía de Microsoft recomienda que la relación de contraste del texto visible sea de al menos 4,5:1, y exige que, cuando el texto se amplía, los controles y contenedores también se redimensionen y reubiquen en consecuencia.56

Además, en cuanto a los temas de contraste se recomienda:7

  • No fijar los colores directamente en el código
  • Usar recursos de tipo SystemColor / Brush
  • Probar con los 4 tipos de tema de contraste

Los puntos donde suele fallar esto son:

  • Etiquetas que asumen un ancho fijo
  • Altura de botón fija en píxeles
  • Un diseño que transmite el significado solo con color
  • UI con dibujo personalizado que no sigue el tema

Este apartado tiene menos que ver con «cumplir con la accesibilidad» y más con lo que conviene entender como el trabajo de base para construir una UI de Windows que no se rompa a largo plazo.

Los cuadros de diálogo son útiles, pero si se usan en exceso se convierten en un enemigo del trabajo.

La guía de cuadros de diálogo de Windows define el diálogo como una UI modal que se usa cuando se necesita una notificación, una aprobación o información adicional, y recomienda colocar al menos una operación segura y no destructiva (Cerrar, Cancelar, etc.). Además, indica que el texto de los botones debería ser una respuesta concreta.10

Lo importante es no convertir todo en un cuadro de diálogo.

En particular, resulta más natural inclinarse por una indicación en línea para:10

  • Los errores de entrada a nivel de campo
  • Los errores de formato que se pueden corregir en el momento
  • Los avisos temporales

7.4 Los comandos importantes deben tener varias rutas de acceso

En el diseño de comandos de Windows se da importancia a que los comandos importantes puedan invocarse desde distintos métodos de entrada y superficies de la UI.1213

Esto también funciona muy bien en la práctica.

Por ejemplo, para «eliminar»:

  • Barra de herramientas
  • Menú contextual
  • Tecla Suprimir
  • Deslizar, si hace falta

Cuando existen varias rutas de este tipo, la experiencia de uso se vuelve más estable.

En sentido contrario, diseños como:

  • Aparece solo al hacer hover, en el extremo derecho
  • Solo aparece con el clic derecho
  • Nunca se puede llegar a él con el teclado

se debilitan de golpe en cuanto cambia el método de entrada.

7.5 Verificar con herramientas de prueba

Es más rápido comprobar la accesibilidad con una herramienta que pensar mentalmente «seguramente está bien».

La guía de pruebas de accesibilidad de Microsoft presenta el uso de Accessibility Insights for Windows para Live Inspect, FastPass y solución de problemas, y además permite verificar con la herramienta Inspect del SDK los atributos y la estructura de navegación de UI Automation.17

Como mínimo conviene hacer esto:

  • Un recorrido general con Accessibility Insights
  • Verificar con Inspect el nombre, el rol y los patrones de los elementos principales
  • Recorrer los flujos principales usando solo el teclado
  • Probar la ampliación de texto y los temas de contraste

Hacer al menos esto reduce el retrabajo posterior.

7.6 Incorporar capacidad de recuperación

Esto no es tanto un punto de la lista de verificación de una línea de Microsoft, sino algo que en la práctica del escritorio de Windows tiene bastante peso.

La UX no se decide solo por «un botón agradable de presionar», sino también por poder volver atrás incluso después de un accidente.

Por ejemplo:

  • Deshacer / Rehacer
  • Guardado automático
  • Conservar el estado en edición
  • Restauración de filtros, orden y ancho de columnas
  • Interrupción y reanudación
  • Progreso y cancelación de procesos largos

influyen en la UX mucho más de lo que parece a simple vista.

En especial en ToB o en herramientas para expertos, el estrés de tener que repetir una operación se traduce directamente en mala UX.

8. Errores de diseño frecuentes

8.1 Suponer que, por ser ToB, basta con alta densidad

Esto solo tiene razón a medias.

Si es para un experto que la usa a diario, la alta densidad puede ayudar. Pero en terminales de campo, terminales de recepción o interfaces de equipos, la densidad es más bien el enemigo.

En lugar de la etiqueta ToB, resulta más confiable mirar el nivel de experiencia, el método de entrada y el entorno de uso.

8.2 Ocultar demasiadas funciones por ser ToC

Incluso en apps personales, si la herramienta es para expertos, la eficiencia es la prioridad absoluta.

Si se inclina todo hacia «mostrarlo fácil» pase lo que pase, empieza un infierno silencioso:

  • Las operaciones de alta frecuencia quedan lejos
  • Hay que ir a escarbar en el menú una y otra vez
  • Se sigue cambiando de pantalla sin parar

8.3 Diseñar operaciones que dependen del hover

El tacto no tiene hover. Además, una UI que solo aparece con el puntero también suele llevarse mal con la tecnología de asistencia.412

Es más seguro que las operaciones importantes estén siempre visibles, o que al menos tengan varias rutas de acceso.

Antes: la operación solo aparece en el extremo derecho de la fila donde hay hover
  Comprobante 1001   2026-03-18   Pendiente                        <- no se ve nada
  Comprobante 1002   2026-03-18   Pendiente        [ Editar ][ Eliminar ] <- solo en la fila con el mouse encima

Después: siempre visible + más rutas de acceso
  Comprobante 1001   2026-03-18   Pendiente        [ Editar ][ Eliminar ]
  Comprobante 1002   2026-03-18   Pendiente        [ Editar ][ Eliminar ]
     Clic derecho  -> Editar / Eliminar
     Teclado       -> Enter para editar, Suprimir para eliminar

8.4 Comunicar el estado solo con color

Es especialmente frecuente en pantallas de monitoreo, pero transmitir el significado solo con rojo/amarillo/verde es peligroso.

Combinar texto, icono, hora, cantidad y descripción reduce tanto los descuidos como las malas interpretaciones.11

Es algo muy frecuente en sistemas de entrada de datos administrativos. Si aparece un diálogo cada vez que se escribe algo, el ritmo de trabajo se rompe por completo.

Un error que está acotado al contexto resulta más natural mostrarlo en el mismo lugar, dentro de la pantalla.10

Antes: modal por cada campo
  Código postal  [ 1234        ]        +------------------------------+
  Dirección      [             ]        | El formato del código postal
                                   |  no es correcto
                                   |                       [ Aceptar ]
                                   +------------------------------

Después: en línea, en el mismo lugar
  Código postal  [ 1234        ]
                 ! Ingrese 7 dígitos numéricos. Ejemplo: 1234567
  Dirección      [             ]

8.6 Construir con un diseño de tamaño fijo

Se ve bien en un entorno de desarrollo con visualización al 100%, pero se rompe fácilmente con:

  • Ampliación de texto
  • DPI alto
  • Temas de contraste
  • Localización

67

Antes: etiqueta de ancho fijo + botón de alto fijo. Al ampliar el texto
  [ Fecha de env... ][ 2026-03-1  ]      <- la etiqueta se corta, el valor se desborda
  [ Reg ][ Can ]                         <- el texto del botón se corta arriba y abajo

Después: un diseño que se estira según el contenido
  Fecha de envío prevista
  [ 2026-03-18              ]
  [ Registrar ]   [ Cancelar ]           <- la altura se decide por el contenido + el margen

Cuanto más se pule el acabado visual, más se convierte en veneno el supuesto de un tamaño fijo.

8.7 Crear demasiados controles personalizados

Los controles estándar de Windows tienen, más allá del aspecto visual, muchos comportamientos incorporados.

  • Foco
  • Teclado
  • Seguimiento del tema
  • UI Automation
  • Conexión con la tecnología de asistencia

Se encargan de cuidar todo esto, así que si sin motivo se construye todo desde cero, aumenta la deuda tanto de UX como de accesibilidad.83

9. Ocho preguntas para decidir antes de empezar

Por último, colocamos 8 preguntas que conviene tener al inicio de una revisión de diseño.

Pregunta Respuesta típica Qué afecta en la UX
1. Quién la usa Principiante / experto / mixto Densidad de información, terminología, flujo inicial, cantidad de ayuda
2. Dónde se usa Escritorio / sala de reuniones / campo / exteriores / recepción Tamaño de botones, tamaño de texto, luminosidad, método de entrada
3. Con qué se opera Teclado / mouse / tacto / lápiz óptico / escáner Orden de tabulación, atajos, zona de impacto, si se puede depender del hover
4. Con qué frecuencia se usa Sobre todo la primera vez / de vez en cuando / a diario / todo el día Si priorizar la facilidad de descubrimiento o la eficiencia
5. Cuál es el costo de un error Leve / grave / peligroso / sujeto a auditoría Flujo de confirmación, deshacer, control de permisos, registros
6. Cuánta información hay en una pantalla Poca / media / mucha Si conviene un formato de tarjetas, centrado en listas, o dividir la pantalla
7. ¿Se necesita personalización? No hace falta / algo necesario / muy necesario Selección de columnas, guardado de disposición, atajos, granularidad de configuración
8. ¿Cuáles son los requisitos de accesibilidad? Mínimos / muy necesarios / orientado al público en general Ampliación de texto, contraste, UIA, lectura en voz alta, esfuerzo de verificación

Al responder antes estas 8 preguntas, se resuelve de forma natural:

  • Si la navegación debería ser poco profunda
  • Si conviene lista + detalle
  • Si conviene reforzar los atajos
  • Dónde usar los cuadros de diálogo
  • Hasta dónde permitir la personalización

10. Resumen

Lo importante en el diseño de UX de una app de Windows es decidir, antes que «¿se ve bien?», «¿esa persona, en ese lugar, con ese método de entrada, puede usarla sin detenerse?».

En resumen, a grandes rasgos:

  • ToC prioriza la comprensión en el primer uso y la sensación de seguridad
  • ToB administrativo prioriza la eficiencia continua y el soporte de teclado
  • ToB de monitoreo prioriza no pasar nada por alto y la operación segura
  • ToB de terminal de campo prioriza objetivos de operación grandes y rutas cortas
  • Las herramientas para expertos priorizan la densidad, los atajos y la personalización
  • Las herramientas residentes priorizan no estorbar

Y, sin importar el uso, lo que funciona en común son estos 6 puntos:

  1. Usar los controles estándar sin modificar
  2. Que las operaciones principales se completen con el teclado
  3. No trabarse con el tacto o la tecnología de asistencia
  4. No romperse con la ampliación de texto o los temas de contraste
  5. Preparar varias rutas de acceso para los comandos importantes
  6. Poder volver atrás incluso después de un accidente

La UX no es un adorno, sino un contrato de operación. Cuanto más encaje ese contrato con el usuario, el entorno y el método de entrada, más discreta —pero más sólidamente— fácil de usar será la app de Windows.

11. Referencias

  1. Microsoft Learn, “Introducción al diseño de apps de Windows - Windows apps” ↩ ↩2 ↩3

  2. Microsoft Learn, “Accessibility - Windows apps” ↩ ↩2 ↩3

  3. Microsoft Learn, “Keyboard accessibility - Windows apps” ↩ ↩2 ↩3 ↩4 ↩5

  4. Microsoft Learn, “Guía para desarrolladores de operación táctil - Windows apps” ↩ ↩2 ↩3 ↩4 ↩5

  5. Microsoft Learn, “Accessible text requirements - Windows apps” ↩ ↩2 ↩3

  6. Microsoft Learn, “Text scaling - Windows apps” ↩ ↩2 ↩3

  7. Microsoft Learn, “Temas de contraste - Windows apps” ↩ ↩2 ↩3

  8. Microsoft Learn, “Fundamentos de navegación de apps de Windows - Windows apps” ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  9. Microsoft Learn, “Access keys design guidelines - Windows apps” ↩ ↩2

  10. Microsoft Learn, “Dialog controls - Windows apps” ↩ ↩2 ↩3 ↩4 ↩5

  11. Microsoft Learn, “Developing inclusive Windows apps” ↩ ↩2

  12. Microsoft Learn, “Commanding in Windows apps using StandardUICommand, XamlUICommand, and ICommand” ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  13. Microsoft Learn, “Commanding basics - Windows apps” ↩ ↩2

  14. Microsoft Learn, “Multiple inputs design guidelines - Windows apps” ↩

  15. Microsoft Learn, “Targeting - Windows apps”. Explica que el objetivo táctil debe tomar como referencia 7,5 mm de lado (40x40 píxeles a 135 PPI y escala 1,0x), que debe agrandarse según la frecuencia de uso y el impacto de un error de operación, y que los controles de WinUI ya siguen esto por defecto. ↩ ↩2 ↩3

  16. Microsoft Learn, “Content layout and spacing - Windows apps”. Indica como referencia un espacio de 8epx entre botones o con un encabezado, 12epx entre etiquetas o áreas de contenido, y 16epx entre el borde de una superficie y el texto. ↩ ↩2 ↩3

  17. Microsoft Learn, “Pruebas de accesibilidad - Windows apps” ↩

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Una app empresarial ToB debería tener siempre una UI de alta densidad, con mucha información?
Solo tiene razón a medias. En sistemas de entrada de datos administrativos usados a diario por personal experimentado, una alta densidad que permita ver mucho de un vistazo y completar todo con el teclado sí ayuda a la eficiencia continua. Pero en terminales de campo o interfaces de equipos como fábricas, almacenes o recepciones, la densidad es más bien el enemigo: hay que priorizar objetivos de operación grandes, rutas cortas y claridad. En lugar de la etiqueta "ToB", es más confiable observar el nivel de experiencia del usuario, el método de entrada y el entorno de uso. A la inversa, incluso en ToC, herramientas avanzadas como edición de imágenes o análisis de inversiones priorizan la densidad de información, los atajos y la personalización por encima de la simplicidad.
¿Qué es lo primero que hay que decidir en el diseño de UX de una app de Windows?
No basta con distinguir entre ToC y ToB; primero conviene poner en palabras cinco preguntas. Quién la usa (principiante, experto o mixto), dónde se usa (escritorio, campo, exteriores, recepción), con qué se opera (teclado, mouse, pantalla táctil, escáner, tecnología de asistencia), con qué frecuencia se usa (sobre todo la primera vez, a diario, todo el día) y cuál es el costo de un error (leve, grave, peligroso, sujeto a auditoría). Una vez claras estas cinco preguntas, resulta mucho más fácil decidir las prioridades de densidad de la UI, navegación, atajos, cuadros de diálogo de confirmación y personalización.
¿Cómo debería elegirse el patrón de navegación?
No existe un único diseño de navegación que funcione para todas las apps; los principios son la consistencia, la simplicidad y la claridad. Como guía general, la navegación superior conviene cuando se quieren mostrar en pantalla todos los elementos de navegación; la navegación lateral izquierda, cuando hay muchos elementos de nivel superior; lista/detalle, para sistemas de entrada de datos donde se cambia de elemento con frecuencia mientras se muestra o actualiza el detalle; las pestañas, cuando se quiere abrir y cerrar dinámicamente varios documentos; y las migas de pan, cuando es fácil perder de vista la ubicación actual en una jerarquía profunda. La navegación no es una preferencia visual, sino un reflejo de la estructura de la información y del trabajo.
¿Hasta qué punto conviene usar cuadros de diálogo de confirmación?
Es importante no convertir todo en un cuadro de diálogo. Los errores de entrada a nivel de campo y los errores de formato que se pueden corregir en el momento se comunican mejor con una indicación en línea dentro de la pantalla, no con un diálogo. Lo que realmente conviene confirmar son las operaciones más bien irreversibles: detener, eliminar, bloquear o sobrescribir. Si se muestra un diálogo, hay tres reglas mínimas que respetar: escribir con claridad en la primera línea qué va a ocurrir, usar en los botones un texto concreto como "Eliminar" o "Detener" en lugar de "Aceptar"/"Sí", y siempre incluir un botón seguro y no destructivo.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Contactar
Volver al blog