Una introducción al diseño para ingenieros

Lo que sigue es una traducción de A Design Primer for Engineers, una entrada del blog Rands in Repose, de Michael Lopp, autor de los libros Being Geek y Managing Humans. Como podréis ver, parte de su carrera profesional se desarrolló en Apple y no tiene un especial gusto por las titulaciones académicas. Sus escritos suelen tener un tono ligeramente ácido y polémico que le han convertido en un blogger (y orador) de referencia en temas de IT Management y… la tensa relación entre ingeniería y diseño.

Para ser una palabra con tanta influencia en la suerte de una empresa, vale la pena recalcar que no existe una definición generalmente aceptada de la palabra diseño. Esto significa que cuando tu jefe se pone de pie frente al equipo en la reunión de departamento y dice: “Vamos a una cultura centrada en el diseño”, existe una alta probabilidad de que no esté diciendo absolutamente nada.

Pero se oye la palabra continuamente. Y, aún más importante, cada vez que la oyes, percibes una sensación de urgencia de ella. Oyes que elegir diseñar algo es importante y la persona que lo dice también es importante, por lo que asientes vigorosamente con la cabeza mientras en silencio piensas “No tengo ni puñetera idea de de qué estamos hablando y estoy bastante seguro de que tú tampoco”.

No hace falta más evidencia de que un enfoque mágico en el diseño puede transformar una empresa. Para que esto suceda, ingeniería y diseño necesitan irse más de fiesta  juntos, pero existe una tensión fundamental entre diseño e ingeniería y entender esa tensión es un buen lugar para empezar a pensar en el diseño.

Una tensión fundamental

Para entender la tensión histórica entre diseñador e ingeniero es necesario retroceder en el tiempo al momento en que el software se volvió mainstream, y en mi opinión eso pasó con la llegada de Internet. El software llevaba mucho tiempo dando vueltas y generando montones de dinero mucho antes de Netscape, pero se convirtió en un fenómeno global en el momento en que cualquiera, en cualquier lugar del mundo, pasó a ser capaz de enviar a cualquier otra persona una foto de su gato.

La llegada de todo el mundo (y sus gatos) representó un desafío para aquellos primeros equipos de desarrollo de software. Esos equipos estaban acostumbrados a trabajar con usuarios adeptos a la tecnología y sus necesidades particulares. Y es que esos adeptos están dispuestos a soportar un montón de porquería — es parte del acuerdo que tenemos con ellos. “Puedes jugar con lo último y lo mejor, pero puede explotar en cualquier momento.” Los adeptos toleran esas explosiones porque ser adeptos les hace sentir bien y, bueno… que molan.

Cuando llegó el resto del mundo, resultó ser que el resto del mundo no quería explosiones: quería que las cosas, simplemente, funcionasen. Cuando un ingeniero oye “simplemente que funcione” escucha “quieren menos explosiones”, pero eso no es lo que todo el mundo quería. Querían enviar una foto de su gato de la forma más sencilla posible. Les daba igual el JavaScript, la seguridad, los frames o los plugins: sólo querían enviar una foto del maldito gato, sin que la aplicación explotase.

El diseño resulta en la traducción tangible entre el pensamiento del ingeniero, “menos explosiones” y el pensamiento del usuario, “enviar la foto del gato de manera fiable, con un solo clic”. El buen diseño se las arregla tanto para destacar lo mejor de los esfuerzos de ingeniería como para ocultarle el resto al usuario.

Después de trabajar con una buena variedad de diseñadores, mi opinión es que el papel del diseño es:

  1. Entender lo que la mayoría de los usuarios quieren.
  2. Priorizar y centrarse en las más importantes de esas necesidades.
  3. Usar este conocimiento para superar las expectativas de los usuarios.

En los años noventa, nosotros, como ingenieros tradicionales, no estábamos equipados para el papel que acabo de describir. Habíamos sido formados como constructores de bits, y creíamos que como éramos capaces construir bits, éramos capaces de construir bits usables, pero en realidad lo que se nos daba bien era el diseño de productos buenos para nosotros mismos… no para todo el mundo.

Nosotros no vemos una explosión como algo malo porque somos íntimamente conscientes de cómo se construyen las cosas. Sabemos que cuando un programa se bloquea, basta con reiniciar la aplicación y volver al trabajo. La mayoría de los seres humanos del planeta no ve de la misma forma una aplicación colgada. En el mejor de los casos, se alarman cuando algo explota. Se preguntan, “¿Se acaba de producir un daño permanente?”

Una nota para el diseñador y el ingeniero

Con disculpas previas al increíble circo de gente dedicada al diseño que corre por ahí, este manual se centra principalmente en los habitantes del mundo del diseño y las prácticas de diseño que rodean al desarrollo de software. Además, este manual lo ha escrito un ingeniero para ingenieros. Aunque he pasado unos cuantos años empapándome de diseño, no soy un diseñador capacitado y las siguientes descripciones de vuestra historia y vuestro arte os cabrearán por su sencillez, imprecisión, incompletitud y sesgo ingenieril.

Pero les estamos haciendo lo mismo a los diseñadores. Tenemos buena intención, pero como no hemos experimentado repetidamente los detalles esenciales, no somos conscientes de ellos. Asumimos que el acto de describir el trabajo es, de alguna forma, equivalente a hacer el trabajo y, vaya si nos equivocamos, pero estamos en buena compañía, porque todo maestro ferviente de su correspondiente oficio lo hace.

Los ingenieros nos sentimos incómodos en la ignorancia y, lo que es peor, se nos da mal pedir ayuda fuera de nuestro ámbito de especialización. Este manual es el primer paso en la construcción de un puente sólido entre nuestras profesiones. Por lo tanto, relájate. Esta no es una guía definitiva del diseño: es un lugar para que los ingenieros comiencen a pensar en el diseño, y si resulta que aprendes algo sobre nuestra forma de pensar, fantástico.

Las siglas importan

Es probable que la primera vez que escuches la frase “necesitamos un diseñador” sea también la primera vez que oigas hablar de diseño como flamante ingeniero de software. Uno se pregunta: “Bueno, ¿qué va a hacer un diseñador que no esté haciendo yo ya?” La respuesta es una lista impresionantemente larga de trabajo que va más allá del alcance de este artículo, pero una buena manera de comenzar es con tres acrónimos clave.

Como cualquier profesión, el diseño está lleno de acrónimos, pero me voy a centrar en los tres que se van a poner muy de moda ahora que tu jefe ha decidido que el diseño importa.

# 1 DG – Diseño Gráfico

Cómo ven el mundo:

Imagen del icono de iTunes muy ampliada

Desafortunadamente, el nombre más común usado para describir al diseñador gráfico es, confusamente, diseñador. Las razones son de dos tipos: en primer lugar, que fue la primera persona contratada para trabajar en el producto con un conjunto de habilidades fuera de la ingeniería y, en segundo lugar, que fue puesto a cargo de “lo bonito”. Alguien que mandaba vio el primer prototipo funcional del producto, y dijo: “Esto parece hecho por un ingeniero” (asientes) y “Necesitamos un diseñador para arreglarlo” (se te queda la mirada en blanco).

Tú: “Arreglar ¿qué?”

Persona que manda: “No sé… sólo tiene que… ser más bonito.”

Los diseñadores que aún no han salido corriendo de este artículo, sin embargo, ahora están de pie gritando a la pantalla mientras leen: “Conozco a ese tío“.

Sí, yo también le conozco. Es tonto, pero tiene buena intención.

El oficio del diseñador gráfico es visual. A través de aplicaciones como Photoshop e Illustrator, un diseñador gráfico da forma visual a las ideas. Sí, el trabajo que realizan es bonito, pero no es sólo bonito. Habla. Tiene una opinión sobre qué es y todo aquel que lo mira ve esa opinión. Sí, un diseñador le da a tu aplicación o sitio web un aire de profesionalismo limpio y creíble, pero una cosa bien dibujada hace bien poco para que el producto resulte más fácil de usar.

Surge un problema cuando la persona que manda entra en la oficina del diseñador gráfico y le dice: “Tú eres el diseñador… ¿puedes ayudar a desingenieralizar el producto?” Ahora, como tú, el diseñador gráfico quiere hacer más —quiere más responsabilidad— así que, aunque no sabe cómo funciona el producto, ni quiénes son los usuarios, se apunta, pensando “Claro, soy diseñador, ¿no?”.

Y entrega. Genera un prototipo agradable a la vista en Photoshop tan atractivo que te gustaría lamerlo. El diseñador gráfico ha hecho algo que la mayoría de ingenieros no puede hacer, pero aunque se ha producido un importante trabajo de diseño, el diseño no está acabado ni de lejos: el producto sólo tiene una cara bonita. Y si bien el aspecto del producto es importante, su funcionamiento es igualmente importante.

Para el final de cada sección de este manual he seleccionado un conjunto de tres libros relacionados con el diseño que han marcado mi opinión del diseño. Vamos a empezar con las bases del diseño:

# 2 DI – Diseño de Interacción

Cómo ve el mundo el DI:

Wireframe cortesía de Jason Robb

El diseñador de interacción tiene un bolo fascinante: abstrae la función de la forma. Piensa en cómo navegas normalmente por tu aplicación favorita. Sigues un camino conocido que vamos a llamar flujo de trabajo: se trata de una serie de acciones del ratón junto con tu magia de tecleo rápido. Esa es tu interfaz con la aplicación.

El bolo del diseñador de interacción es el cuidado y alimentación del flujo de trabajo. A través del hábil uso de wireframes y diagramas de flujo, el diseñador de interacción define y refina el proceso paso a paso por el que un usuario recorre la aplicación.

Estas descripciones de baja fidelidad de la funcionalidad son confusas para los que no entienden su intención. ¿Será este el aspecto de la aplicación? No, esto es la interacción. Son aproximaciones groseras de la interfaz de usuario que pretenden describir cómo funcionará, no su aspecto. Pero ¿qué aspecto tendrá? ¿Podríamos sombrear ese texto? Me encantan los sombreados y el azul, me encantan los textos con pegada. Sí, está bien, vale… ahora tiene usted que irse. La puerta es por el pasillo a la izquierda y es de un tono azul precioso.

La separación de función y forma implica un salto mental y hay quienes creen que una no puede considerarse sin la otra. Yo creo que la respuesta está en algún lugar en el medio. Aunque no creo que se necesiten composiciones perfectas hasta el último píxel para pensar estratégicamente sobre la interacción, creo que los prototipos funcionales con interacciones y animación de ejemplo son un lugar mucho más rico para sostener un debate que una pizarra.

Un garabato de baja fidelidad puede describir cómo funciona el producto, y elimina muchos de los elementos subjetivos de diseño capaces de hacer descarrilar una buena conversación sobre diseño en un debate inútil sobre sombras. Pero el color, la tipografía, el espacio… todos estos elementos contribuyen a la sensación que da el producto, y la sensación del producto es igualmente importante al cómo funciona.

Hay otras dos siglas en órbita cercana al DI que probablemente vayas a descubrir y que vale la pena mencionar:

AI o arquitecto de información es un título que en los últimos años está cayendo en desgracia. Tal vez el mejor modelo para pensar acerca de los AIs es el papel de un bibliotecario. La mentalidad de los arquitectos de la información es lo que nos dio el sistema decimal Dewey: un sistema de clasificación de la información. Un AI no duerme bien hasta que la información se ha organizado. No me he cruzado con una de estas personas en mucho tiempo.

HCI o Human Computer Interaction es otro título que descubrirás. Al parecer, este título es una exclusiva concedida por las universidades y los que lo ostentan primero declaran el grado, luego hacen una pausa y, a continuación, añaden su universidad. Sí, tengo un doctorado en HCI <pausa> por Carnegie Mellon.

Mi experiencia con la gente de HCI es que con frecuencia son investigadores brillantes. Si quieres entender cualquier posible flujo de trabajo que los usuarios están probando con tu aplicación, el tiempo transcurrido para completar estos flujos de trabajo, y el conjunto enumerado de daños emocionales cuantificables que estos flujos de trabajo están provocando a los usuarios, buscas un buen HCI, le das 18 meses, y quedarás <pause> deslumbrado.

Continuando con la lista de lecturas. Estos libros los seleccioné porque creo que son accesibles para cualquiera. Leerlos no te dará una educación de diseño completa, te dará una buena y sólida idea de las diferentes partes del diseño:

# 3 UXD – Diseño de Experiencia de Usuario

Encontrar la imagen que describe cómo piensa un UxD es difícil, así que ahí van tres (haz clic en cada una para obtener más detalles):

El espectro de la experiencia de usuario según Information Architects, Inc. Incluye diseño, comunicación corporativa, negocio, lógica de negocio, tecnología y lógica interactivca, con sus diferentes interaccionesLa rueda de la experiencia de usuario. Incluye las fases estratégica, de producción, de desarrollo y conceptualLa telaraña de la experiencia de usuario. Añade a las cuatro fases, entre otros, la accesibilidad, la usabilidad, la deseabilidad, la utilidad y la inspiración

Diseño. Experiencia. Usuario. ¿Qué es lo que importa? Bueno, importa el maldito conjunto. Te preocupa el diseño visual, te preocupa el diseño de interacción, pero sobre todo lo que te importa es la experiencia del usuario.

En mi experiencia, la gente que se etiqueta como UxD no tiene nada que ver con un título en UxD. Es un título que han ido adoptando a lo largo de los años, porque saben lo que yo también sé: el título de diseñador es demasiado general para ser útil. Diseñador gráfico y diseñador de interacción son demasiado específicos. Los diseñadores de experiencia de usuario probablemente tenían algún otro acrónimo en el pasado, pero en alguna parte del viaje decidieron que saldrían ganando preocupándose de todo el maldito producto.

Impresionante.

Hay un montón de disciplinas de diseño que contribuyen con sus siglas y capacidades a los esfuerzos de diseño de producto y hay un tiempo y lugar para cada una. La razón por la que busco a la persona que se etiqueta o piensa en sí misma como UxD es porque busco una persona dispuesta a dar un paso adelante y responsabilizarse de toda la experiencia.

La última parte de la lista de lectura incluye clásicos absolutos de diseño. Sí, un libro sobre cómics:

Más. Fiestas. Juntos.

La usabilidad como disciplina de diseño está notoriamente ausente de esta lista. La cosa es que ni aunque tuviese un acrónimo chulo no la incluiría.

Antes de la vuelta de Steve Jobs a Apple, había un equipo decente de usabilidad centralizado, equipado con esas salas con espejos dobles y cámaras de vídeo. Estoy seguro de que hacían un trabajo importante, pero cuando Jobs regresó, cerró el departamento y diseminó los equipos de diseño. Cada equipo de producto heredó parte del antiguo equipo de usabilidad.

Ahora, yo llegué después de que se produjese esta reorganización, por lo que no conozco el razonamiento real, pero sí sé que nunca vi los laboratorios en uso ni una vez, y diría que en la última década Apple ha creado algunos de los productos más usables que existen. Mi opinión es que la opción de extender la función de diseño de usabilidad al equipo de ingeniería pretendía enviar un mensaje claro: ingeniero y diseñador necesitan ir más de fiesta… juntos.

No me imagino construir un equipo responsable de productos de consumo en que ingenieros y diseñadores no estén en constante intromisión en los negocios del otro. Sí, a menudo discuten desde lados completamente opuestos del cerebro. Sí, a menudo es una batalla entre arte y ciencia, pero ingeniería y diseño pretenden exactamente lo mismo. Quieren llegar a la intensa satisfacción de saber que han construido con éxito algo que importa.

Una cultura centrada en el diseño es una frase vacía, de usar y tirar, a menos que todos los responsables de la cultura del diseño se encuentren cara a cara. Los títulos y acrónimos dan un punto de partida para entender lo que una persona puede hacer, pero lo que realmente importa es el respeto que se produce cuando te tomas el tiempo tiempo necesario para entender cómo construyen lo que les gusta.

CC BY-NC-SA 4.0 Una introducción al diseño para ingenieros por cesar está licenciado bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com... Valora en Bitacoras.com: Lo que sigue es una traducción de A Design Primer for Engineers, una entrada…

Comentar

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Leer entrada anterior
Management, leadership y un poco de fútbol

Si, como decíamos hace poco, la gestión de la IT en la empresa es fundamentalmente, pues eso, gestión (“IT management...

Cerrar