Escuchar antes de diseñar: lo que enseña un proyecto para aprender braille

01Lo esencial

• Un equipo estudiantil entregó cerca de 60 dispositivos y más de 30 versiones Mini a una escuela especializada.
• El diseño cambió tras escuchar a quienes enseñan y aprenden braille.
• El método sirve para plataformas corporativas: investigación primero, forma después, y pensar en quién lo mantendrá.

Cerca de 60 dispositivos y más de 30 versiones pequeñas fue lo que un equipo estudiantil de robótica entregó a una escuela para personas con discapacidad visual, tras cerca de un año de trabajo y dos meses de producción. El resultado importa menos que el camino: antes de diseñar, el equipo se sentó a escuchar.

El proyecto se llama BraiPop!, y lo desarrolló el equipo Blue Ignition de una preparatoria tecnológica de Saltillo. Para un comité que aprueba plataformas internas, portales o herramientas de operación, es una lección de método con la forma de un caso pequeño.

02Qué descubrieron al escuchar

En una primera visita a una asociación local que trabaja con personas con discapacidad visual, el mentor del equipo recibió comentarios sobre la propuesta inicial y conoció los métodos de enseñanza. Ahí apareció una dificultad concreta: al escribir braille con regleta y punzón, los puntos se marcan desde un lado de la hoja y después hay que voltearla para leer el relieve.

Quien aprende debe hacer dos acciones distintas con herramientas distintas. Esa observación cambió el diseño. El equipo buscó una herramienta que permitiera practicar ambas cosas en el mismo dispositivo.

03Cómo quedó el producto

• Cada dispositivo tiene 6 botones que suben y bajan para representar las combinaciones del sistema braille.
• Las piezas se unen entre sí para formar palabras.
• Se diseñó con modelado 3D y pasó por varias modificaciones antes de producirse.
• Existe una versión pequeña, llamada Mini.

04El método, traducido a una plataforma corporativa

Un equipo de producto de una empresa grande suele empezar con un requerimiento escrito por un área y una pantalla dibujada por otra. El caso invierte la secuencia: observación del uso real, hallazgo de una fricción concreta, y solo entonces diseño.

• Visita de campo: observa cómo se resuelve hoy el problema, con las herramientas que la gente ya usa.
• Fricción concreta: busca el paso que obliga a hacer dos acciones donde debería haber una.
• Prototipo temprano: prueba una versión sencilla con quienes lo usarán, antes de pulir.
• Iteración: acepta que el diseño pasará por varias modificaciones.
• Continuidad: define quién lo mantendrá y lo seguirá usando.

Esa última decisión es de diseño. Los dispositivos se entregaron a la escuela y no a personas en lo individual, para que los usen nuevos estudiantes durante varios ciclos. Pensar en quién lo seguirá usando es parte del producto.

05Lo que dijo el mentor

Resumió la experiencia con una frase sencilla: de lo que más aprendieron no fue de braille, sino de inclusión. Para una organización, la traducción es directa. Diseñar con las personas, no para ellas, cambia el resultado y también a quienes participan.

Una lectura para el área de tecnología: la mayoría de los proyectos internos fallan en adopción, no en ingeniería. Un sistema bien construido que obliga a los usuarios a dar un paso extra o a cambiar de herramienta a mitad de tarea se abandona. Detectar esa fricción con una visita de media tarde es mucho más barato que corregirla después del lanzamiento.

También hay un ángulo de gobierno. Cuando varias áreas piden requerimientos distintos para la misma plataforma, el criterio de decisión más sólido es lo que se observó en campo. Eso reduce discusiones de opinión y le da al comité un hecho que defender. Un registro simple de hallazgos de campo, con fecha, lugar y persona, ya cumple esa función.

Y un último punto: la accesibilidad no es un módulo que se añade al final. Si el diseño parte de usuarios con necesidades distintas, el resultado suele funcionar mejor para todos. Una interfaz clara para quien tiene una limitación casi siempre es más clara para quien está cansado, con prisa o en un lugar con mala señal.

El mejor sistema de diseño empieza con una visita y una libreta, no con una pantalla en blanco.

06Errores que conviene evitar

• Diseñar para personas sin haberlas escuchado.
• Resolver el problema que imaginas y no el que existe.
• Entregar un producto sin pensar en quién lo mantendrá o lo seguirá usando.
• Presentar el proyecto como un favor y no como una colaboración.
• Pulir el diseño antes de probar un prototipo sencillo.

07Y en México

El caso es de Saltillo y de una escuela local, y eso le da una enseñanza clara: la investigación de campo no requiere una consultora internacional. Un grupo con operación en México puede abrir sus proyectos con tres visitas a quienes usarán el sistema, ya sean vendedores en sucursal, almacenistas, técnicos de ruta o personal de atención, y llevar a la mesa lo que vieron, no lo que supuso el área central.

08Checklist para aplicarlo

• Antes de diseñar, conversa con tres personas que usarían tu producto.
• Anota la dificultad concreta que describen, no la que supones.
• Prueba un prototipo sencillo con ellas.
• Define quién lo mantendrá y lo seguirá usando.

09Para aplicar hoy

Antes de tu próxima plataforma o herramienta interna, visita a una persona que la usará y pídele que te muestre cómo resuelve hoy el problema. Anota lo que te sorprenda.