El oficio más allá del código: diseño, percepción y respeto

Llega un punto en la formación de cualquier profesional en el que el conocimiento técnico deja de ser el factor limitante. Se domina el framework, se sabe medir, se sabe estructurar, y sin embargo el resultado sigue sin tener esa cualidad difícil de nombrar que tienen las aplicaciones que dan gusto usar. La distancia que queda no se cruza con más API: se cruza con criterio. Y el criterio, aunque suene inefable, tiene estructura y puede estudiarse. Se apoya en tres pilares concretos: entender las guías de interfaz humana como una gramática compartida con la plataforma y no como un manual de estilo, entender que la velocidad que importa es la percibida y obedece a leyes de la psicología con nombre propio, y entender que cada decisión de producto gasta recursos que no son tuyos —la atención, la batería, los datos y la privacidad de otra persona—. Esta lección trata de eso, y es la única del track donde el compilador no puede ayudarte.

Antes de entrar, conviene desactivar una objeción frecuente: el diseño no es mi trabajo. En equipos grandes hay especialistas y su criterio manda, pero incluso ahí quien programa toma cada día decenas de microdecisiones de diseño que ninguna maqueta especifica —qué pasa mientras carga, qué dice el mensaje cuando falla, dónde va el foco al abrir, qué ocurre si la lista está vacía, qué se anima y qué no—. Esas decisiones, sumadas, son la experiencia real del producto. No delegarlas no es invadir competencias ajenas: es hacer bien la parte que inevitablemente te toca.

Las guías de interfaz humana como gramática

El error habitual al leer las guías de Apple es tratarlas como un catálogo de reglas estéticas. Son otra cosa. Son la descripción de un conjunto de convenciones que millones de personas ya han aprendido sin darse cuenta: que deslizar desde el borde izquierdo vuelve atrás, que un gesto hacia abajo cierra una hoja, que un texto en color es tocable, que el botón destructivo aparece en rojo y pide confirmación, que la barra de navegación anuncia dónde estás. Cada convención respetada es trabajo cognitivo que tu app no le pide a nadie, porque ya está pagado por el resto del sistema.

De ahí se sigue el criterio para apartarse de ellas, que es más matizado que sigue siempre las guías. Apartarse cuesta atención de la persona usuaria y por tanto necesita comprar algo con ella. Un juego, una herramienta creativa o una app cuya identidad visual es el producto tienen razones legítimas para inventar su propio lenguaje. Una app de banca o de productividad que reinventa la navegación no está siendo original: está cobrando un impuesto de aprendizaje a cambio de nada. La pregunta operativa es siempre la misma: qué gana quien usa la app con esta desviación, y si la respuesta es destacar, no es una respuesta.

Hay además un beneficio técnico que suele pasarse por alto. Los componentes nativos traen gratis un conjunto enorme de comportamientos que reimplementar cuesta meses y sale mal: accesibilidad completa, Dynamic Type, modo oscuro, teclado externo, reducción de movimiento, texto de derecha a izquierda, control por voz. Cada control propio que sustituye a uno del sistema hereda la obligación de reproducir todo eso, y el nivel 19 ya mostró lo que ocurre cuando no se hace.

Rendimiento percibido: el tiempo que se siente

El nivel 24 midió el rendimiento con instrumentos. Esta sección trata de algo distinto y complementario: la velocidad que la gente experimenta, que no es una función lineal del tiempo transcurrido. La psicología de la interacción lleva décadas trabajando con tres umbrales estables. Por debajo de una décima de segundo, la respuesta se percibe como instantánea y como causada por el propio gesto. Hasta aproximadamente un segundo, el flujo de pensamiento se mantiene aunque se note la demora. Más allá de unos diez segundos, la atención se va a otra parte y hace falta algo que la retenga.

Esos umbrales dictan tácticas concretas. Todo toque debe producir realimentación inmediata, aunque el trabajo real tarde: un cambio de estado visual bajo el dedo cuesta cero y transforma la sensación de la app. Toda operación cuyo éxito es abrumadoramente probable —marcar una tarea, dar a me gusta, guardar una nota— debe aplicarse de forma optimista en la interfaz y reconciliarse después, lo que además encaja de forma natural con la cola de operaciones del plano de arquitectura. Y toda espera larga debe mostrar progreso honesto, no una rueda eterna que no informa de nada.

// Optimista: la interfaz refleja la intencion al instante y el
// sistema reconcilia despues. El fallo se revierte y se explica.
@MainActor
func alternarCompletada(_ tarea: Tarea) async {
    let previo = tarea.completada
    tarea.completada.toggle()                 // efecto inmediato
    do {
        try await repositorio.guardar(tarea)  // se encola, no bloquea
    } catch {
        tarea.completada = previo             // reversion visible
        aviso = .noSePudoGuardar
    }
}

Los estados de carga merecen su propio criterio porque casi siempre se resuelven mal. Una pantalla que salta de vacía a rueda y de rueda a contenido produce dos saltos visuales y la sensación de tirones. Un esqueleto que reserva el espacio con la forma del contenido futuro elimina el desplazamiento del layout y hace que la aparición del dato se perciba como llegada y no como sustitución. Y hay un detalle contraintuitivo que conviene retener: si la operación termina en menos de unos doscientos milisegundos, mostrar el indicador es peor que no mostrar nada, porque un parpadeo se percibe como un fallo. Retrasar el indicador es a menudo la mejora de rendimiento percibido más barata que existe.

flowchart TD
T[Toque] --> R[Realimentacion visual inmediata bajo el dedo]
R --> D[Duracion estimada de la operacion]
D -->|menos de 200 ms| N[No mostrar indicador]
D -->|hasta 2 segundos| E[Esqueleto con la forma del contenido]
D -->|mas de 2 segundos| P[Progreso honesto y opcion de cancelar]
N --> C[Contenido]
E --> C
P --> C
style R fill:#a6e3a1,color:#11111b
style C fill:#89b4fa,color:#11111b
style P fill:#fab387,color:#11111b

La animación, bien entendida, pertenece a este mismo capítulo. Su función no es decorar sino explicar la continuidad: una hoja que sube desde el botón que la invocó dice de dónde viene y adónde volverá; una fila que se desplaza para dejar sitio a otra dice que la lista cambió y cómo. Una animación que no explica nada solo añade espera, y esa es la prueba a la que conviene someter cada una: si al quitarla la pantalla se entiende igual, sobraba. Y todas deben respetar la preferencia de movimiento reducido, que no significa quitar la animación sino sustituirla por un fundido.

El respeto como decisión de ingeniería

Hay una dimensión del oficio que se enuncia con palabras grandes —respeto, ética— y que en la práctica se concreta en decisiones de ingeniería muy pequeñas y muy concretas. Los recursos que tu app gasta no son suyos: la atención, la batería, los datos móviles, el almacenamiento y la información personal pertenecen a otra persona que te los presta.

La atención se gasta con notificaciones. Una notificación que no vale la interrupción que provoca es un préstamo que no se devuelve, y el castigo es proporcional: la gente desactiva el permiso entero y pierdes también las que sí importaban. La regla práctica es que una notificación debe ser algo que la persona habría querido saber aunque hubiera tenido que pagar por ello. La batería se gasta con trabajo en segundo plano, con sondeos periódicos y con actualizaciones de ubicación de precisión innecesaria. Los datos se gastan con imágenes sin dimensionar y con sincronizaciones que no distinguen la red del móvil de la del hogar. Y la privacidad se gasta con cada permiso que se pide y cada dato que se recoge por si acaso.

En este último punto la plataforma ya ha tomado partido, y conviene ver el marco de privacidad de Apple —los manifiestos, las descripciones de uso obligatorias, la transparencia de seguimiento, las etiquetas de la ficha— no como burocracia sino como la formalización de un principio simple: pedir lo mínimo, en el momento en que se entiende por qué, y explicarlo con palabras verdaderas. Un permiso solicitado al arrancar, antes de que nadie sepa para qué sirve la app, se deniega mucho más y a menudo para siempre. El mismo permiso pedido justo cuando la persona intenta hacer lo que lo requiere se concede casi siempre. Es diseño, y también es respeto, y además funciona mejor.

Cómo se forma el criterio

Queda la pregunta práctica: si el criterio no se aprende en la documentación, dónde se aprende. Se entrena con tres hábitos que cualquiera puede sostener. El primero es la crítica dirigida: usar a diario aplicaciones excelentes preguntándose no si gustan, sino qué hicieron exactamente para que se sientan así —dónde pusieron el foco al abrir, qué mostraron mientras cargaba, qué dijeron cuando algo falló, qué no animaron—. El gusto sin análisis es imitación; el análisis convierte la observación en repertorio.

El segundo es ver usar la app a otra persona sin ayudarla. Media hora de esta observación desmonta más suposiciones que un trimestre de discusiones internas, porque revela el abismo entre el modelo mental de quien construyó la pantalla y el de quien llega sin contexto. Y el tercero es una disciplina del detalle: una lista de estados que ninguna maqueta suele especificar —vacío, cargando, error de red, sin permiso, contenido larguísimo, texto al tamaño máximo, sin conexión, primera vez— y que hay que resolver a conciencia en cada pantalla. La calidad percibida de un producto se decide casi por completo en esos ocho estados, y son exactamente los que se dejan para el final y se resuelven con prisa.