Hay palabras que utilizamos todos los días sin preguntarnos nunca de dónde vienen.
“Bug” es una de ellas.
La usamos cuando una aplicación falla, una web hace algo extraño o un programa decide que hoy tampoco piensa colaborar.
Pero la historia detrás de esta palabra es bastante más curiosa.
Porque en 1947 hubo un momento en el que un bug informático fue literalmente un bicho.
Aunque hay un pequeño detalle que conviene aclarar:
La palabra “bug” no nació aquel día.
Y precisamente por eso la historia es todavía más interesante.
Antes de los ordenadores ya existían los “bugs”
Mucho antes de que existieran los ordenadores modernos, ingenieros y técnicos ya utilizaban la palabra bug para referirse a pequeños fallos o defectos en máquinas y sistemas eléctricos.
El Smithsonian señala que el término llevaba utilizándose durante más de un siglo para describir problemas en máquinas y que incluso Thomas Edison hablaba de “bugs” en circuitos eléctricos durante la década de 1870.
Así que cuando llegaron los primeros ordenadores, la palabra ya estaba preparada.
Solo necesitaba encontrar al protagonista perfecto.
Y lo encontró en una polilla.
El día que apareció un bug de verdad
En 1947, un equipo de ingenieros trabajaba con el Harvard Mark II, uno de los primeros grandes sistemas electromecánicos de computación.
Una noche, la máquina dejó de funcionar correctamente.
El equipo comenzó a buscar el problema.
Y lo encontró dentro de uno de los relés:
una polilla atrapada en el mecanismo.
Los ingenieros retiraron el insecto y lo pegaron en el cuaderno de registro de la máquina junto a una anotación que hacía referencia al “primer caso real de bug encontrado”.
Y ahí tenemos una de las anécdotas más famosas de la historia de la informática.
No porque aquella polilla inventara la palabra.
Sino porque convirtió una expresión técnica en una imagen imposible de olvidar.
Un bug.
Literalmente.
Grace Hopper y una historia que se hizo todavía más grande
En el equipo que trabajaba con el Mark II estaba Grace Hopper, matemática, programadora y posteriormente oficial de la Marina estadounidense.
Hopper no fue necesariamente quien escribió aquella anotación —el propio Smithsonian indica que el cuaderno probablemente no era suyo—, pero sí contribuyó a popularizar el uso de “bug” y “debug” en el mundo de la informática.
De hecho, Hopper conservó y contó posteriormente la historia del insecto encontrado en el ordenador.
Con el tiempo, “bug” pasó a formar parte del vocabulario habitual de la programación.
Y “debug” se convirtió en una de esas palabras que cualquier persona que haya trabajado con tecnología conoce perfectamente.
Pero ¿qué tiene que ver esto con el diseño?
Aquí es donde la historia se pone interesante.
Porque un bug no siempre aparece como un error evidente.
A veces todo parece funcionar.
La web carga.
El logotipo está terminado.
Los colores combinan.
La tipografía es bonita.
El cliente está contento.
Y, sin embargo, algo no termina de funcionar.
Eso también puede ser un bug.
Solo que no aparece en una línea de código.
Aparece en la estrategia.
El bug de una marca que nadie entiende
Imagina una empresa que ofrece un servicio excelente, pero cuando alguien entra en su web no entiende exactamente qué hace.
Todo funciona técnicamente.
Pero el mensaje falla.
Tenemos un bug.
O una marca que utiliza cinco estilos gráficos diferentes según quién haya preparado la publicación de Instagram.
Tenemos otro.
O un logotipo que se ve perfecto en una presentación de 2.000 píxeles, pero se convierte en una mancha ilegible cuando aparece pequeño.
Otro bug.
Y quizá uno de los más habituales:
Una identidad visual preciosa que no conecta con las personas a las que pretende dirigirse.
Visualmente funciona.
Estratégicamente, no.
Bug.
Los bugs del diseño suelen esconderse a plena vista
Esta es quizá la parte más interesante.
Los errores de diseño no siempre llaman la atención.
De hecho, muchas veces ocurre justo lo contrario.
Se camuflan.
Un mensaje demasiado largo.
Una jerarquía visual confusa.
Un botón que nadie encuentra.
Una tipografía difícil de leer.
Una paleta de colores que no transmite lo que debería.
Un catálogo en el que todo tiene el mismo nivel de importancia.
Una marca que cambia de personalidad cada semana.
Ninguno de estos problemas tiene por qué provocar un error evidente.
Pero todos pueden estar perjudicando el resultado.
El diseño también necesita “debugging”
Cuando hablamos de diseño gráfico solemos pensar en crear.
Crear un logotipo.
Crear una web.
Crear un cartel.
Crear una identidad.
Pero una parte fundamental del trabajo consiste precisamente en detectar lo que no funciona.
Preguntar.
Observar.
Comparar.
Probar.
Eliminar.
Volver a probar.
Eso también es diseñar.
En programación, hacer debugging significa localizar el problema y corregirlo.
En diseño podemos hacer exactamente lo mismo.
¿Por qué nadie entiende este mensaje?
¿Por qué esta marca parece una empresa diferente en cada soporte?
¿Por qué este botón no recibe clics?
¿Por qué este logotipo pierde fuerza cuando se reproduce pequeño?
¿Por qué una identidad que sobre el papel parecía perfecta no está funcionando en la realidad?
Ahí empieza el verdadero trabajo.
No siempre necesitas empezar de cero
Y esta es una idea especialmente importante para cualquier empresa.
Detectar un problema no significa necesariamente tirar todo y empezar otra vez.
A veces el bug está en una pequeña parte del sistema.
Quizá el problema no sea el logotipo.
Quizá sea cómo se está utilizando.
Quizá no necesites una nueva web.
Quizá necesites reorganizar el contenido.
Quizá no necesites cambiar todos los colores.
Quizá necesites establecer una jerarquía visual clara.
Quizá no necesites una identidad completamente nueva.
Quizá necesites definir primero qué quieres comunicar.
Primero se encuentra el bug. Después se decide qué hacer con él.
Diseñar también es encontrar lo que falla
Esta es una de las razones por las que el diseño gráfico no debería reducirse a “hacer cosas bonitas”.
Un diseñador no debería limitarse a decorar una solución que ya existe.
También debería ser capaz de detectar problemas.
Porque muchas veces el cliente llega diciendo:
“Necesito un logo nuevo”.
Y después de hablar un rato descubrimos que el problema real estaba en otra parte.
En el mensaje.
En el posicionamiento.
En la estructura.
En la experiencia.
En la forma en la que la marca se presenta.
El logotipo era simplemente el síntoma.
La polilla no era el problema
Y quizá aquí esté la mejor metáfora de toda esta historia.
En 1947 encontraron una polilla dentro del Mark II.
Era un problema real.
Pero el verdadero trabajo consistió en encontrarla.
Con las marcas sucede algo parecido.
Cuando algo no funciona, lo fácil es cambiar cosas al azar.
Otro color.
Otro tipo de letra.
Otro logo.
Otra web.
Otro anuncio.
Pero cambiar cosas sin saber qué está fallando es como abrir un ordenador, sacar componentes al azar y esperar que vuelva a funcionar.
Primero hay que encontrar el bug.
¿Tiene tu marca algún bug?
Puede que no sea evidente.
Quizá tu marca funciona perfectamente.
O quizá llevas meses pensando:
“Hay algo que no termina de encajar”.
Puede que ese “algo” tenga nombre.
Un mensaje poco claro.
Una identidad incoherente.
Una web difícil de entender.
Un diseño que no está pensado para tu público.
O simplemente una estrategia que nunca llegó a definirse.
No todos los bugs hacen que una pantalla se quede en blanco.
Algunos simplemente hacen que una marca funcione peor de lo que podría.
Y esos son, precisamente, los más difíciles de encontrar.
Porque están ahí.
Funcionando.
Pero mal.
Conclusión
La historia del bug más famoso de la informática tiene una moraleja que va mucho más allá de aquella polilla de 1947.
Los sistemas complejos pueden fallar por algo diminuto.
Y las marcas también.
Un pequeño problema de jerarquía puede hacer que un mensaje no se entienda.
Una decisión aparentemente insignificante puede romper la coherencia de toda una identidad.
Un detalle puede cambiar por completo la experiencia.
Por eso diseñar no consiste únicamente en crear.
También consiste en detectar, probar, corregir y volver a probar.
En otras palabras:
hacer debugging.
Porque a veces tu marca no necesita empezar de cero.
Solo necesita que alguien encuentre la polilla.