Si una pantalla necesita manual, está mal hecha

Una pantalla de un programa de gestión está bien hecha cuando la persona que la va a usar entiende qué hacer sin que nadie se lo explique. Si hace falta un manual, una formación o un pósit pegado en el monitor, el fallo es del programa, no de quien lo usa. Y en una pyme, donde nadie tiene tiempo para cursos, ese fallo se paga cada día.

Te cuento cómo lo aprendí.

¿Qué pasó con el filtro que fallaba en silencio?

Pasó que una recepcionista de una clínica creó 41 pacientes duplicados en dos meses, y durante esos dos meses todos pensamos que el problema era ella.

La aplicación tenía un buscador de pacientes. Escribías el apellido y salía la ficha. Funcionaba perfectamente cuando lo probaba yo.

Pero ella escribía "Garcia" sin tilde. El buscador buscaba "García" con tilde. No encontraba nada. Y en lugar de decir "no hay nadie con ese nombre, prueba de otra forma", la pantalla se quedaba en blanco.

Ella, con un paciente delante y otro esperando, hacía lo lógico. Si no está, lo doy de alta. Y así, 41 veces.

Cuando me llamaron, la primera frase fue "creo que Marta no sabe usar el buscador". Tardé una tarde en darme cuenta de que Marta lo usaba bien. El buscador fallaba sin avisar, y un programa que falla sin avisar convierte un error suyo en un error tuyo.

Arreglarlo fueron veinte minutos. Buscar sin distinguir tildes ni mayúsculas, y avisar de pacientes parecidos antes de crear uno nuevo. Limpiar los duplicados llevó dos días.

¿Por qué los programas se hacen para quien los programa?

Porque quien los programa los prueba con sus manos, sus datos y su tiempo. Sabe qué hace cada botón porque lo ha hecho él. Escribe los nombres como los escribe él. Y nunca tiene un paciente delante mirándole.

Me pasa a mí también. Por eso he dejado de fiarme de mis propias pruebas.

El que va a usar la pantalla es otra persona. Un repartidor con guantes. Una fisioterapeuta entre dos sesiones, con 40 segundos. Un encargado de obra con el sol dando en el móvil. Si la pantalla no funciona para ellos, no funciona.

¿Cómo se diseña para alguien que no es técnico?

Se diseña quitando decisiones, no añadiendo instrucciones. Estas son las reglas que sigo en todas las aplicaciones que hago:

• Desplegables en vez de texto libre. Si el dato tiene cinco valores posibles, que se elijan, no que se escriban. "Pagado", "pagado.", "PAGADO" y "pagao" son cuatro estados distintos para un programa.
• Nada que falle en silencio. Si algo no se ha guardado, si una búsqueda no encuentra nada o si un envío ha fallado, la pantalla lo dice con palabras normales y propone qué hacer.
• Un botón principal por pantalla. El que se usa el 90 % de las veces, grande y en el mismo sitio siempre. El resto, más discreto.
• Palabras del negocio, no del programador. "Paciente", no "usuario". "Albarán", no "documento de entrega". Si en tu empresa se dice "parte", la pantalla dice "parte".
• Valores por defecto sensatos. La fecha de hoy, el cliente de la última vez, la cantidad de siempre. Que lo normal no haya que escribirlo.
• Deshacer mejor que confirmar. Un "¿seguro que quieres...?" en cada acción se acaba pulsando sin leer. Poder deshacer durante unos segundos protege más.

Ninguna de estas reglas es original. Pero es sorprendente la cantidad de programas de gestión que no cumplen ni la mitad.

¿Cómo sé si una pantalla está bien hecha?

Lo sabes viendo a alguien usarla sin ayuda. No preguntándole si le gusta. Mirando.

En cada proyecto hago lo mismo. Le doy el móvil o el ordenador a la persona que la va a usar, le digo qué tiene que conseguir y me callo. No le explico nada. Apunto dónde duda, dónde se equivoca y dónde me mira buscando ayuda.

Cada duda es un defecto de la pantalla. Cada mirada, también.

Es incómodo. La primera vez que lo hice tuve que morderme la lengua cinco o seis veces. Pero en diez minutos aprendes más que en una semana de reuniones sobre "qué campos queremos".

Esto lo meto desde el principio, en la primera semana de un proyecto conmigo. Antes de programar nada serio, ya hay alguien del equipo tocando pantallas de prueba.

¿Y la formación, entonces, no sirve?

Sirve para lo raro, no para lo de todos los días. Está bien que alguien sepa cómo se hace el cierre de trimestre, que es una vez cada tres meses. No está bien que haga falta formación para dar de alta un pedido, que se hace treinta veces al día.

Mi regla es sencilla. Si una tarea se repite cada día, tiene que salir a la primera sin ayuda. Si se hace una vez al mes, puede llevar una pantalla más explicada. Si se hace una vez al año, puede llevar incluso una guía.

Y hay otra ventaja que se ve con el tiempo. Cuando entra una persona nueva en la empresa, no hay que dedicarle una semana a enseñarle el programa. Se sienta y trabaja.

¿No es esto un capricho de diseño?

No. Es dinero. Una pantalla confusa cuesta minutos cada vez que se usa, errores que alguien tiene que arreglar y datos sucios que luego nadie se cree.

Los 41 duplicados de la clínica se tradujeron en historiales repartidos entre dos fichas, bonos descontados de la ficha equivocada y un paciente que recibió dos recordatorios de la misma cita. Nada grave. Pero todo evitable.

Con la IA escribiendo cada vez más código, esto va a pesar más, no menos. Generar pantallas es cada vez más fácil. Pensar para quién son sigue siendo igual de difícil. Lo cuento más en por qué generar código no es avanzar.

Si alguien en tu empresa "no sabe usar el programa", mira primero el programa.

Y si tienes un programa que tu equipo usa a regañadientes, reserva una llamada de 30 minutos y me enseñas las pantallas que más les cuestan.