Cita en territorio desconocido: los diseñadores B2E al encuentro de los expertos del sector

Diseñar con herramientas especializadas complejas sin conocer el sector es una situación habitual para los diseñadores que trabajan en proyectos especializados. ¿Por dónde empezar? ¿Cómo entender lo que realmente hacen los expertos? ¿Cuándo y cómo involucrarlos en el diseño? Estos son los métodos que he ido desarrollado a lo largo de mis proyectos en los sectores aeroespacial, de los medios de comunicación y de I+D.

Todo diseñador B2E ha vivido ese primer día en el que no entiende ni una palabra de lo que dicen los expertos del sector. Términos técnicos, procesos que encajan entre sí, una fluidez entre ellos que lleva años adquirir y una única pregunta: ¿por dónde empezar?

Ante esta pregunta, hay dos trampas que hay conviene evitar. La primera es querer entenderlo todo antes de atreverse a proponer nada, aspirando a un nivel de experiencia que no se puede alcanzar en unas pocas semanas. La segunda es hacer justo lo contrario y conformarse con ejecutar lo que se nos pide, sin cuestionarlo nunca. En ambos casos, el diseñador no encuentra su lugar ni consigue generar impacto.

Mis diferentes proyectos me han enseñado una cosa: un buen diseñador B2E no trabaja solo frente a su pantalla, sino codo con codo con los expertos del sector. En este artículo, os doy algunos consejos para conseguirlo.

Por dónde empezar: la inmersión como método, acelerada por la IA

La inmersión es la primera fase de cualquier proyecto en un ámbito complejo, y no se hace desde la oficina. Lo primero es salir a conocer gente, estar presente tanto en los momentos informales como en las reuniones programadas y hacer preguntas. Aprender un ámbito profesional se parece a aprender un idioma: escuchas los mismos términos en contextos diferentes y, poco a poco, empiezas a entender importancia relativa. Dejas de apuntar las palabras que no entiendes y empiezas a comprender lo que implican.

Esta inmersión debe estar estructurada para que resulte eficaz. Recurro sistemáticamente a modelos que me ayudan a dar forma a toda la información recopilada: user journey maps para trazar el recorrido de principio a fin, ampliaciones de partes específicas del flujo de trabajo y service blueprints para situar las herramientas lo que busco sobre todo es identificar las zonas de incertidumbre en las que necesito profundizar. Incluso un mapa incompleto resulta útil, porque señala con precisión dónde falta información. La investigación con usuarios es el núcleo de este trabajo: empiezo definiendo el alcance con el Product Manager (PM) o el Product Owner (PO) y después voy directamente a hablar con los usuarios. Las primeras conversaciones pueden parecer confusas, pero las cosas se van aclarando rápido.

En una de mis misiones, me asignaron más de cinco productos diferentes desde el principio: herramientas internas para equipos de investigación, interfaces para el análisis de grandes volúmenes de datos o incluso temas relacionados con el descubrimiento de moléculas. El verdadero reto consistía en ponerme al día rápidamente en tantos ámbitos a la vez sin dejar de aportar valor.

La IA cambió las reglas del juego: me permitió consultar directamente la documentación disponible e identificar rápido lo que ya entendía y lo que aún me faltaba por comprender. Lo que antes habría requerido varias semanas de lectura y sistematización se convirtió en un proceso iterativo en el que podía delimitar un tema en cuestión de días. Cada vez más empresas cuentan con una IA interna que permite consultar su documentación. Es una herramienta que merece la pena aprovechar al comienzo de un proyecto para preparar las entrevistas y sacarles partido casi de inmediato.

Trabajar con los expertos: del cuestionario a la facilitación

Cuando se trabaja con herramientas profesionales complejas, los expertos del sector rara vez conocen el papel del diseñador. Saben lo que necesitan, pero no siempre tienen claro qué puede aportar un diseñador para mejorar su flujo de trabajo.

Es a través de las conversaciones cuando ese valor empieza a hacerse evidente. Un diseñador que plantea buenas preguntas, se familiariza con la terminología del sector y vuelve con hipótesis que contrastar, en lugar de con afirmaciones, va demostrando poco a poco lo que puede aportar.

Con el tiempo, este trabajo de asimilación cambia la naturaleza de las conversaciones. Los expertos profundizan en sus explicaciones sin sentir la necesidad de simplificarlas. Cuando perciben que su razonamiento se comprende, el diseñador pasa a convertirse en un facilitador: alguien que ayuda a formalizar aquello que nunca se había expresado con claridad y que detecta tensiones que la propia cercanía al tema impedía ver. Es este papel el que le otorga la legitimidad para proponer, cuestionar y, en ocasiones, desafiar.

Tener ciertos conocimientos básicos sobre el sector ayuda (mi formación científica me ha proporcionado a menudo un buen punto de partida para abordar cuestiones técnicas), pero lo que realmente marca la diferencia es la curiosidad: interesarse de verdad por lo que hacen los expertos, hacer preguntas sin miedo a parecer novato, volver con lo que hemos entendido para que ellos mismos lo validen.

Basarse en los modelos mentales: meterse en la mente de los expertos

El objetivo es representar con precisión la forma en que piensan los expertos cuando trabajan, más que dominar el sector en sí mismo. Procedente de las ciencias cognitivas, el concepto de modelo mental fue aplicado al diseño por Donald Norman en The Design of Everyday Things (1988): el usuario se construye una representación de cómo funciona algo y es la interfaz la que debe acercarse a esa representación, no al revés. Este enfoque cambia la perspectiva: se trata de entender qué hace el experto, por qué lo hace y en qué orden.

En la práctica, hay varias señales que indican que hemos alcanzado un nivel de comprensión suficiente. Hemos identificado todas las etapas del proceso, tanto dentro como fuera de la herramienta. Hemos analizado cada dato para decidir cómo integrarlo. Conocemos con precisión la secuencia y la cronología de los pasos, identificamos cómo se interconectan las herramientas y cómo circulan los datos. Llegados a este punto, tenemos una idea muy concreta de la arquitectura de la interfaz y de la navegación. Es a continuación, durante el diseño, cuando surgen otras preguntas: en una interfaz, nada se deja nada al azar.

En una empresa del sector aeroespacial, creé vídeos formativos sobre movimientos mecánicos precisos para el montaje de satélites, actividades en las que un error de ejecución puede salir muy caro. Para ayudar a los operarios a comprender cómo manejar herramientas a medida, elaboré representaciones esquemáticas animadas de su funcionamiento, de manera que pudieran aprender rápidamente y actuaran sin cometer errores. Elegí este tipo de representación porque los operarios están acostumbrados a manipular objetos y a ver cómo se mueven en el espacio. Les exigía menos esfuerzo que imaginar el comportamiento de una pieza a partir de una imagen y un procedimiento escrito. No dominaba la mecánica: trabajé con los ingenieros para entendder su lógica y me basé en su experiencia en cada etapa de validación. Al final, el ingeniero responsable me dijo: "Es una locura, te has metido en mi cabeza". Una señal de que lo que habíamos conseguido comprender no era únicamente el ámbito de especialización, sino la forma en que el experto lo concibe.

Pensar en objetos de negocio para diseñar correctamente

Si los modelos mentales representan cómo piensa el experto, los objetos de negocio permiten traducir ese pensamiento en una estructura de interfaz. Surgen de forma natural a medida que nos sumergimos en el tema: son los conceptos que los expertos nombran de forma espontánea, aquellos en torno a los que se organizan sus tareas y toman sus decisiones.

En una empresa de streaming dirigida al gran público, trabajé en la remodelación de un backoffice que permitía organizar el trabajo editorial en la plataforma front-end. Los objetos centrales eran Programas, Páginas, Reproductores, Bloques de contenido y Listas de programas. Entender las relaciones entre estos objetos nos permitió determinar qué información era esencial en cada pantalla y cuál era secundaria, sin partir de lo que ya mostraba la interfaz existente.

La metodología Object-Oriented UX, desarrollada por Sophia V. Prater, formaliza precisamente esta idea. Parte de las entidades centrales del sistema, traza un mapa de sus relaciones y define qué información debe mostrar cada objeto al usuario en función de su estado. Este enfoque resulta especialmente útil en el contexto de rediseño: permite desmontar la arquitectura existente y detectar sus incoherencias incluso antes de empezar a trabajar en un primer boceto.

Sin este trabajo previo, corremos el riesgo de separar información que por naturaleza debería permanecer unida o de diseñar pantallas que parecen lógicas de manera aislada, pero pierden su coherencia dentro del flujo global.

Co-construir las soluciones con los expertos

La fase de co-construcción llega cuando se ha acumulado suficiente material como para empezar a proponer las primeras líneas de actuación. En este punto, pasamos de las entrevistas exploratorias a una dinámica más activa: presentamos un material a los expertos y construimos a partir de sus reacciones.

Este material puede adoptar formas muy diferentes en función de las respuestas que necesitemos obtener. Si se quiere probar una primera línea de arquitectura de la información, un taller de card sorting suele ser lo más eficaz: permite observar cómo los expertos organizan los conceptos de manera natural. Si el flujo de trabajo todavía está incompleto y quedan zonas por aclarar, podemos representarlo en un tablero y organizar un taller para completar con ellos, en directo, aquello que falta. Por último, cuando las primeras propuestas están lo suficientemente desarrolladas como para poder cuestionarlas, los tests con usuarios toman el relevo para validar o invalidar las hipótesis.

La clave es llegar con algo que cuestionar o completar. No tiene por qué ser necesariamente un prototipo: querer presentar pantallas demasiado pronto es un reflejo habitual, pero a menudo contraproducente. Un flujo de trabajo mal definido y validado en un prototipo generará problemas más adelante. Los modelos de flujo suelen ser mucho más eficaces para detectar los casos límite: esos que a los expertos quizá no se les habría ocurrido mencionar espontáneamente, pero que aparecen en cuanto tienen delante algo concreto sobre lo que reaccionar.

Las preguntas que guían este trabajo son siempre las mismas: ¿se mantienen las líneas generales? ¿Pueden los expertos llevar a cabo realmente aquello que es importante en su trabajo? 

En mi proyecto, de rediseño del back-office de una plataforma de streaming, identificamos los «Jobs-to-be-Done» (JTBD) como los elementos estructurantes de toda la remodelación, para asegurarnos de que cada decisión contribuyera a ellos. Esta matriz, combinada con los modelos mentales y los objetos de negocio, orienta las preguntas que planteamos en los talleres, la forma en que se analizamos las reacciones y las decisiones de diseño que extraemos de ellas.

Identificar la información fundamental para el diseño

A medida que avanzamos en el proyecto, los intercambios con los expertos se profundizan y la información se acumula. Entrevistas, talleres, modelos: el volumen de información pronto se vuelve considerable. Entonces, ¿qué debemos utilizar realmente para diseñar y en qué momento?

Hay información que es fundamental: si se descubre demasiado tarde, pone en tela de juicio decisiones ya tomadas y nos obliga a empezar de cero (los objetos de negocio son un ejemplo perfecto). Otra es secundaria: por ejemplo, puede servir para perfeccionar una pantalla o añadir un filtro de búsqueda, pero no altera la estructura fundamental del flujo. Hacer esta distinción desde el principio permite diseñar sobre bases sólidas sin bloquear las decisiones indefinidamente.

En una herramienta de creación de placas de muestras para investigadores de un gigante de la cosmética, necesitaba comprender desde el principio una cosa: ¿existe algún momento en el flujo de trabajo a partir del cual lo que hacemos se vuelve irreversible? La respuesta era sí: una vez que la placa se envía al robot, ya no se puede modificar nada. Este punto de no retorno acabó estructurando todo: dos fases diferenciadas en la interfaz, una lógica de estados que recorre todo el proceso e interacciones diferentes según si se está en fase de preparación o de ejecución. Si lo hubiera descubierto después de crear los primeros bocetos, habría tenido que volver a empezar desde cero. En cambio, enterarme sobre la marcha de que la placa tenía 36 posiciones en lugar de 48 no desestabilizó nada, ni tampoco la incorporación de dos filtros adicionales a la tabla de resultados de los experimentos.

En definitiva, no hay que tener miedo de sumergirse en la complejidad: ese es precisamente nuestro papel como diseñadores, conseguir que las herramientas se integren de forma natural en el día a día de quienes las utilizan.

Por su posición, el diseñador suele tener una visión transversal que le permite plantear preguntas fundamentales y ayudar a los expertos a formalizar sus procesos y sus conocimientos profesionales. También aporta un método para conseguir que las herramientas se integren en el trabajo cotidiano de los usuarios: la inmersión, los modelos mentales y la distinción entre información fundamental y secundaria son sus pilares. Una vez incorporada, esta forma de trabajar cambia tanto lo que podemos aportar como la legitimidad con la que podemos defender nuestras propuestas.