Una mirada progresiva y orgánica a la visualización de ventas

Postgrado Visualización de la Información
IDEC - Universitat Pompeu Fabra
Treensights
Una mirada
progresiva y orgánica
a la visualización de
ventas
Equipo CuaTreeGram:
Judith Argila
Hermes Carretero
Gilbert Martínez
Ricardo Vega
Profesores:
Juan Carlos Dürsteler
Victor Pascual
Alejandro Ramírez
Barcelona 2011 - 2012

Postgrado Visualización de la Información
IDEC - Universitat Pompeu Fabra
Treensights
Una mirada
progresiva y orgánica
a la visualización de
ventas
Equipo CuaTreeGram:
Judith Argila
Hermes Carretero
Gilbert Martínez
Ricardo Vega
Profesores:
Juan Carlos Dürsteler
Victor Pascual
Alejandro Ramírez
Barcelona 2011 - 2012

Informe Proyecto Final
Treensights. Una mirada progresiva y orgánica a la
visualización de ventas.
Postgrado Visualización de la información
IDEC - Universitat Pompeu Fabra
Profesores:
Juan Carlos Dürsteler
Víctor Pascual
Alejandro Ramírez
Alumnos:
Judith Argila
Hermes Carretero
Gilbert Martínez
Ricardo Vega
Barcelona 2011 - 2012

Agradecimientos:
Judith Argila: a las conversaciones con Pau sobre arte, que alimentaron mis
obsesiones, y a We feel fine, que me metió definitivamente en esta historia
Hermes Carretero: a Marta y Crapulesque por el apoyo incondicional, a Gabri,
Víctor y Dani por las asistencias ténicas, y a mis infatigables compañeros de
esta aventura por su fiereza visualizadora.
Gilbert Matínez: al sentido del humor y a la realidad sin sentido. A la tortilla de
patatas en general y a la de mi madre en particular.
Ricardo Vega: a una ratona, una ratoncita, a un par de dinosaurios, a mis compañeros,
y sobre todo a mí mismo por aguantarme a mí mismo. Y a FONDART...

Contenidos
0. Presentación 1. Explorando el terreno
1.1. Exploración conceptual
1.2. Exploración estadística
1.3. Limpieza y filtrado
2. Marcando los límites
2.1. Para quién trabajamos
2.2. Y al principio fue el caos…
2.3. Definiendo el problema
3. Se busca metáfora
visual
3.1. Planta un árbol
3.2. Exploratory Metaphora
Analysis (EMA)
3.3. Un ADN económico
3.4. Multipanel: show them
all
3.5. Un Frankenstein y un
Jackpot
3.6. Crisis, waffles y vuelta a
las raíces
4. Codificación visual
4.1. Valores y atributos: baile
de parejas
4.2. Datos categóricos
4.3. Datos numéricos
4.3.1. La fuerza representativa
de un isotipo
4.4. Dimensión geográfica
4.5. Dimensión temporal
4.6. Últimos ajustes

5. Definiendo la
interacción
5.1. El camino de la navegación
5.2. Selección de variables
5.3. Selección temporal
5.4. Interacción en los árboles:
focus&context
5.5. El camino de regreso
5.6. Recorridos simulados
6. Test de evaluación y
usabilidad
6.1. Primeros pasos hacia una
heurística de la visualización
6.2. Autoevaluación heurística
y recorridos cognitivos
6.3. Test de usuario
7. Código
7.1. Antecedentes
7.2. Librerías
7.3. Funcional
7.2. Generación de datos
estructurados
7.2. Recuperación y procesado
de datos
7.2. Lógica de presentación
8. Visualización final
8.1. Gráfico principal: árboles
8.2. Gráfico secundario: mapa
con burbujas
8.3. Gráfico secundario: mapa
de provincias por colores
Anexos
9.1. EDA ampliada
9.2. Personas y escenarios
9.3. Modelo de heurística
9.4. Prototipos
9.5. Presentaciones
9.6. Formato maquetación

Presentación
Esta es la historia de un proyecto. En concreto, de uno de los proyectos finales que se realizaron para
la primera edición del Posgrado de Visualización de la Información, de la Universidad Pompeu Fabra,
en mayo de 2012.
La petición académica inicial era la creación de una visualización a partir de una base de datos determinada:
la del registro de ventas del año 2008 de una respetada empresa catalana. El objetivo era
aplicar los conocimientos y metodologías aprendidos durante el curso para generar un sistema visual
que aportara valor y luz a un problema determinado. Definir cuál era ese problema formaba parte del
reto del proyecto.
Las páginas que siguen son una crónica de cómo el grupo de los CuaTreeGrams (anteriormente también
conocidos como “Los Topos” y como “Los Tres Tristes Trees”) se enfrentaron al reto, fase a fase,
hasta llegar a la Visualización final. Por el camino se encontraron con ideas descabelladas, centenares
de gráficos parciales, un parto, metáforas de todo pelaje, librerías indómitas, festivales de Eurovisión
y recorridos de interacción imposibles dignos de una ilustración de Escher. Hemos intentado recoger
aquí todos esos pasos, las ideas aceptadas y las descartadas, la evolución y las conclusiones y, de vez en
cuando, también algo del humor y el sentimiento que han ido empapando el proyecto.
Antes de emprender la lectura, vaya por delante un descubrimiento: la realidad siempre resulta mucho
más caótica, irracional e inenarrable de lo que los diagramas del buen infovisualizador apuntan, así que
este documento es a la vez testimonio y ejercicio de ordenación de ideas. Confiamos en que sirva para
que otros revivan con nosotros las discusiones, conclusiones, sufrimientos y locuras (placenteras) de
estos dos meses; para nosotros, queda como recuerdo y guía de referencia para futuros proyectos.

Las 3 preguntas clave para sobrevivir a un proyecto de infovis:
¿Pero Valencia no era ayer de color amarillo? (Herramientas)
¿Seguro que estamos trabajando sobre la misma versión? (Organización)
¿Cada cúanto dices que tiene contracciones? (Entorno)

1 O
explorando el terreno
cómo los Raiders of the Lost Lens
nos perdimos en los datos y finalmente
encontramos un camino

1. explorando el terreno
Freemind categorías web.
Freemind que refleja la estructura
conceptual de lentes de la
empresa catalana, según su web.
En negrita, aquellas categorías
que tienen más visibilidad en los
menús.
12
Un dataset de 7 millones de registros es, sin duda, un lugar interesante para empezar un proyecto. En
nuestro caso, se trataba de un fragmento de la base de datos de una conocida empresa catalana, que
nos facilitó sus registros de ventas del año 2008 con la esperanza de que pudiéramos aportar alguna
visualización que arrojara nueva luz sobre las siempre misteriosas y cambiantes corrientes de mercado.
Con ese ambiguo objetivo en mente, iniciamos nuestro proyecto: primer paso, descarga e instalación de
los datos.
Para saber realmente a qué nos enfrentábamos, necesitábamos tantear el terreno: explorar la base de
datos para, por una parte, entender su estructura, y por otra, empezar a visualizar los datos para detectar
los primeros patrones y los posibles errores. Nuestra exploración tenía que ser tanto conceptual
como estadística.
Exploración conceptual
Un ‘cuadro’ para colgar en la pared cada vez que trabajemos.
Empezamos por el más básico y rupestre de los Exploratory Data Analysis (EDA): la lectura de la web de
la empresa catalana, en una primera aproximación para entender cómo presenta y organiza ella misma
su propio negocio. Allí encontramos la explicación de en qué categorías se organizan sus productos, así
como los atributos que se utilizan para esa clasificación. Con esa información, sumada a la que la responsable
de Data Mining de la empresa nos había facilitado, empezábamos a tener datos contextuales
con los que dotar de sentido e interpretación a los datos en bruto del dataset.
Para ser honestos con nuestra naturaleza visual, necesitábamos poder ver esa jerarquía y esos metadatos
que nos definen las categorías de un modo más gráfico y menos abstracto; ver algo más palpable. ¿Y
qué hay menos abstracto y más palpable que una representación realista de la realidad? Echando mano
de Illustrator, dibujamos la siguiente ilustración, que es, a su vez, un diagrama de relación.
En la imagen de la lente añadimos también la información del porcentaje de referencias (# SKUs/total
SKUs) para cada característica de las variables principales de la lente.
Así, casi el 100% de las referencias de lentes, son o bien progresivas o bien monofocales. Casi el 80% del
total están realizadas en material orgánico y el tratamiento más de ‘moda’ es el HC. El reparto de SKUs
de lentes dedicados a las 2 marcas (A y C) es bastante equlibrado (55%/45% respectivamente)

1. explorando el terreno
Estructura de la lente y relación
con variables de la BBDD
La ilustración incluye el reparto
de SKUs en función de diferentes
variables.
Relación entre las distintas variables
con Parallel Sets
Detección de la relación entre las
variables en función del número
de SKUs comunes.
Entender la jerarquía no nos permitía, sin embargo, conocer la “intensidad” de las relaciones entre
las categorías: esa información se escondía en el volumen de registros del dataset. Así que empezamos
a procesar los datos para poder hacer representaciones visuales exploratorias que nos mostraran
qué categorías tenían más vínculos entre ellas; es decir, qué categorías aparecían más frecuentemente
juntas en el catálogo que refleja todas las referencias posibles de la empresa catalana (de su listado
estructural de SKUs, no de sus transacciones).
Para ello utilizamos el programa Parallel Sets. Creamos una tabla con el archivo cuadroequivalencias.
xls facilitado con la documentación del dataset y cruzamos los datos a partir de los campos “Familias”,
“Material” y “Capa”. Esto fue lo que obtuvimos:
Así se puede verificar rápidamente que, a nivel de tipo de foco, todos aquellos que empiezan por ‘F. _’
corresponden a la marca C y que los bifocales (3ªcolumna) sólo existen para la marca A.
13

1. explorando el terreno
Relación entre Capa y Materiales
con Parallel Sets.
Detalle de la relación entre diferentes
tipos de capa y los materiales.
Algunas capas sólo se
aplican a materiales específicos.
Proceso de Preparación y Exploratory
Data Analysis
Fases y recursos utilizados en la
Exploración de los Datos.
14
También se puede confirmar el protagonismo de las referencias orgánicas, en cuanto a #SKUs, vs. las
minerales o las que usan el policarbonato, éste último (3) sólo se fabrica para la marca A.
Explorando el nivel de capa (tratamiento aplicado a la lente) en función del tipo de material ya
vemos que algunos tratamientos sólo se aplican a las SKUs orgánicas (las primeras columnas
que corresponden a Transitions, Blanco, varios ‘Color*…’) mientras que hay otros como
el AR, HC o el Foto-HC que se aplican tanto al material orgánico como al mineral e incluso el
policarbonato (caso de AR y HC).
Exploración estadística
Por fin teníamos un pequeño mapa de referencia encima de la mesa: habíamos pisado el territorio, observado
su flora y su fauna, y entendíamos qué tipo de relaciones –y cuan intensas- había entre ellas. Ya
no había excusa para seguir postergándolo: debíamos empezar a visualizar las ventas.
Dicha visualización se realizó en el marco de todo un proceso de fusión, limpieza y exploración de la
BBDD. Se incluyen las herramientas de software usadas en cada paso así como las funciones clave que
permiten realizar esos procesos.
Las primeras consultas sobre una parte del dataset (Enero’08) nos mostraron que el 80% de las ventas
y el margen de la empresa catalana tenían su origen en España (el segundo lugar era para Francia, con
un 6%). ¿Podríamos quizá centrarnos en visualizar datos sobre España, evitando la complejidad que
implicaba tener en cuenta todos los países? Consideramos que, dada su predominancia en los registros,
nuestras visualizaciones de España ofrecerían respuestas al menos para una parte importante de las
posibles preguntas de negocio. Estábamos ante un ejemplo paradigmático del 80/20 paretiano, y pare-

1. explorando el terreno
Ventas Brutas y VEA x países.
Concentración de ventas y margen
en España.
Ventas Brutas x geografías de
España
Concentración de ventas por provincias.
Necesidad de disponer
de datos normalizados por población.
cía sensato aplicarlo simplificando el problema pero preservando la parte más importante del output
económico de la empresa.
A partir de una base completa de los datos anuales de España se extrajo (con ‘R’) una muestra aleatoria
de 10.000 casos de las ventas (margen error estadístico +/-1%). A partir de ella (Tablas y Gráficos Dinámicos
Excel) exploramos la base para detectar los primeros patrones y atipicidades.
A nuestros ojos, estos fueron los principales patrones destacables:
• Existe un desfase entre las ventas de BCN y Madrid (superiores en BCN a pesar de tener menos
población). Por tanto normalizar las ventas por la población, para destacar ventas atípicas en relación
a la demografía, nos parece una opción interesante a explorar en el proyecto.
15

1. explorando el terreno
Impacto de variables en ventas
(CHAID).
Exploración del impacto de las
diferentes categorías de las variables
de la BBDD en las ventas
de la empresa catalana.
Ventas según año de
lanzamiento
Concentración de las ventas en
productos lanzados especialmente
en el 2000 y 2005.
16
• Introduciendo algunas variables en un análisis estadístico multivariable CHAID (Chi Square Automatic
Interaction Detection) podemos ver cuáles de ellas generan más impacto en las ventas
promedio por transacción.
Así, mientras que el promedio de transacción de una venta de lentes orgánicas o de policarbonato
está en 81.7 euros, si la lente fuese de la marca C la venta bajaría hasta los 57.5 mientras que si se
tratase de la marca A ascendería a 89.1. Dentro de este mismo tipo de lentes de Marca A podemos
ver diferencias notables de transacción media entre provincias: desde los 65.1 euros (p.ej. Guipúzcoa,
Burgos…) y los 113.6 euros (Barcelona, Ávila…).
• A nivel de innovación vemos que existe una cierta acumulación de ventas del 2008 en referencias
introducidas en años puntuales.
Así, en el año 2000, la empresa catalana introdujo un número importante de referencias relacionadas
con lentes monofocales y bifocales las cuales seguían catalogadas en el 2008. En el 2005
se produjeron innovaciones relacionadas con lentes orgánicas y algunas en el 2007 relacionadas
sobre todo con lentes progresivas orgánicas.

1. explorando el terreno
Tabla resumen de valores
atípicos VN y VEA
Resumen de elementos que
presentan porcentajes altos de
valores atípicos superiores o inferiores.
• A nivel geográfico (provincias) existe suficiente variabilidad de comportamiento en relación a los
mixes de producto o a los porcentajes de ventas/márgenes atípicos (positivos o negativos). En las
tablas siguientes se resume la situación de datos atípicos para diferentes variables confrontando lo
obtenido en VN y VEA. Ver anexo para el detalle de todos los análisis de valores atípicos realizados
(definición atípicos, atípicos x niveles, x capas, x red de ventas…).
Idealmente un caso atípico en VN (venta neta) debería verse reflejado en ese mismo caso apareciendo
como VEA (margen) atípico, aunque no siempre es así. En negrita se marcan aquellos casos en que no
coinciden ambas tendencias.
Afinando aún más allá en el análisis, hay casos que no destacan ni por arriba (no presentan un porcentaje
muy alto de atípicos superiores) ni por abajo (ídem para los atípicos inferiores) pero en cambio muestran
un perfil diferencial en la relación entre VN y VEA. En el gráfico anexo se muestran dichos casos.
17

1. explorando el terreno
Biplot atípicos por
geografía, VN y VEA
Relación entre los atípicos de VN
y VEA para detectar incoherencias
entre ellos.
18
Por ejemplo, Ávila tiene un porcentaje promedio (10%) de valores atípicos superiores en VN pero en
cambio no muestra un porcentaje de valores atípicos de VEA en consonancia con ese dato, en realidad
no tiene ninguno.
Esos son casos de ventas que tampoco se corresponden con sus márgenes (posibles promociones puntuales
de colocación de producto sobrante).
En cambio en zonas como Baleares, Almería, Burgos…se consiguen entre un 10-15% de casos con márgenes
atípicamente altos pero con no más de un 5% de ventas atípicamente altas. Es decir ventas con
transacciones que no son especialmente elevadas pueden llegar a generar márgenes atípicamente elevados
quizás por el mix de productos que se vendan en esa zona.
Y tras ver este mapa de situación, habiéndole tomado el primer pulso a los datos, empezamos a afilar
la podadora.
Limpieza y filtrado
Camaradas, hoy he montado exitosamente la BD para el proyecto (bombos, platillos y cornetas).
Datos en bruto
Recibimos un pack compuesto por:
• 12 archivos .csv que contienen la totalidad, un archivo por mes, de las transacciones realizadas
durante 2008. Cada transacción identificada con el número de familia registra a su vez 6 valores de
importe correspondientes a:
• UNF: unidades físicas vendidas de una familia
• UNI: unidad física + tratamiento vendidas de una familia
• VN: venta neta
• VB: venta total sin restar descuentos

1. explorando el terreno
Diagrama entidad-relación
• VBE: venta bruta para descuentos fuera de factura
• VEA: beneficio resultante de restar costes de ventas a la venta neta
• Archivos de apoyo (equivalencias xls) donde se incluyen las referencias a los códigos presentes en
las transacciones (geográficos, vendedor, tipo de pedido, código de mercado,...) y la tabla clave de
referencias para los identificadores en subfamilias. Esta tabla nos da información para cada familia
estructurada así:
• Propiedades
• Material
• Año de lanzamiento
• Refracción
• Tratamiento
• Su desglose en subfamilias
• Marca (N2)
• Foco (N3)
• Foco + Material (N4)
• Foco + Material + Refracción (N5)
• Foco + Material + Refracción + Tratamiento
Carga de datos en sql
La importación de los datos en nuestra base de datos da como resultado la siguiente estructura:
Tenemos una tabla valores con aproximadamente 7.2 millones de registros de ventas (divididos entre
6 valores de importe para cada transacción), y otra con 1.247 registros únicos de identificación de producto
por familias. Complementariamente hemos creado tablas auxiliares conteniendo las referencias
para los códigos geográficos, los meses y los códigos de cliente.
Limpieza
Una vez cargados los datos, procedemos a su limpieza elemental y regularización:
• Eliminación de espacios en blanco
• Búsqueda y reemplazo de valores nulos
• Eliminación de columnas con valores repetidos (marca = familias)
• Mejora de legilibilidad de los registros (suprimir referencias internas - paréntesis con valores
directorios)
• Agregación de índices e identificadores únicos a las tablas
19

1. explorando el terreno
Modelo anidado
20
Filtrado
Durante la fase de EDA y el desarrollo de la visualización hemos filtrado los datos para:
• Mercado español
• Valores importe VN, VEA y UNF/UNI
• Unido los valores de foco y añadido el valor marca-blanca para aquellos campos precedidos por F.
• Rangos de tiempo por trimestres. Se añade un campo de datos por trimestres para su posible uso
posterior.
Transformaciones
Debido a la complejidad entre las relaciones de la clasificación de productos y con la metáfora del árbol
en la cabeza ,nuestro reto es representar de forma jerárquica el conjunto de ventas para poder establecer
las comparaciones dentro de cada nivel de jerarquía. Otra idea de fondo es que los niveles para
estructurar los datos fueran configurables, es decir poder partir de cualquiera de las propiedades para
ir desglosando el árbol.
Demasiado evidente, pero para tener una representación en forma de árbol los datos deben adoptar esta
forma. Manos a la obra, intentamos conseguir eso en 3 tentativas, por 3 vías diferentes.
Opción 1
Realizar consultas sql a la BD y generar por medio de funciones recursivas PHP la estructura de datos:
//Tree of options with results
foreach($results as $result){
if(!isset($filledTree[$result['material']][$result['refraccion']]
[$result['foco']][$result['tratamiento']])) {
$filledTree[$result['material']][$result['refraccion']][$result['foco']]
[$result['tratamiento']] = array();
}
array_push($filledTree[$result['material']][$result['refraccion']]
[$result['foco']][$result['tratamiento']], $result);
}
Opción 2
Realizar transformaciones en la BD para reproducir las relaciones entre los campos. Probamos tres
aproximaciones al modelo:
• The Adjacency List Model
• The Nested Set Model

1. explorando el terreno
Árbol de directorios
Y una tercera:
• Directory Tree
Opción 3
La tercera y solución definitiva es un programa creado en java (Víctor) que estructura un csv plano
(familias) en nodos y subnodos y relaciona estos con los valores de importe (vn, vea, vb,...) acumulados
en otro csv.
Conclusiones
Finalmente conseguimos un archivo estructurado en forma de árbol :) y quedamos preparados para el
siguiente reto, recuperar la información y cargarla sobre nuestra aplicación de visualización. La estructura
del archivo json quedaría así:
nombre : VN,
children:[{
name: marca a,
children:[{
name : monofocales,
children: [{
name: organico
children: [{
name: trat-col,
children: [{
name: 118,
importe_vn: 1000
},
{
name: 118,
importe_vn: 2000
}...
Tecnologías
MySQL PHPMyAdmin, PHP, Javascript, Eclipse, Google Refine.
21

1. explorando el terreno
22

2
marcando los límites del terreno
De cómo descubrimos para quién
trabajamos y escogimos, por una vez,
nuestros problemas

2. Marcando los límites
Diagrama de Venn: Personas.
El diagrama muestra las principales
áreas / datos de interés de
cada uno de los perfiles de usuarios
potenciales o “Personas”. La
confluencia de las respectivas
áreas de interés marca aquellos
datos que tienen interés para un
mayor número de usuarios; en
nuestro caso, la información más
relevante parecía ser la Venta Neta
(VN), en el centro del diagrama.
Los colores se utilizan categóricamente
para diferenciar a los
personajes. La pregunta que formulan
es un ejemplo que intenta
sintetizar la principal preocupación
o problema de aquél usuario.
Cualquier parecido entre las ilustraciones
y la realidad es mera
coincidencia.
24
Con los datos limpios y dispuestos, el siguiente paso para seguir adelante era definir cuál iba a ser
nuestro problema. Sabíamos que era precipitado lanzarnos a elaborar una definición que forzosamente
limitaría –a la par que enfocaría- el proyecto, y éramos conscientes que la fórmula con la que diéramos
aquellos primeros días sería modificada y ajustada a lo largo del proceso. Pero necesitábamos un primer
trazado, un primer dibujo de los márgenes de la parcela en la que queríamos movernos. Necesitábamos
un problema.
¿Para quién trabajamos?
En realidad, no se trataba de inventar un problema imaginario. Tras nuestro dataset, existía un colectivo
de profesionales que en su día a día lidiaba con los datos buscando respuestas que no siempre eran
obvias: ellos tenían ya, de hecho, problemas reales que necesitaban soluciones reales.
Así que contactamos con una responsable de la empresa para que nos ayudara a identificar qué perfiles
profesionales podían sacar provecho de nuestra visualización, cuáles eran sus responsabilidades y qué
tipo de conocimiento e información necesitaban conseguir. Utilizamos una técnica de diseño y usabilidad
llamada Personas y Escenarios para bajar al detalle esos usuarios potenciales, y localizar en qué
situaciones y circunstancias iban a utilizar la visualización.
Resumiendo, los usuarios potenciales que detectamos fueron los siguientes:
• Director financiero
• Director de Marketing
• Director de Ventas España
• Responsable de Business Intelligence

2. Marcando los límites
Brainstorming categorizado
Sobre la puerta de un lavabo que
muestra medio objeto gráfico, ordenamos
los pósits con todas las
ideas. La ordenación se realizó
según el tipo de información que
queríamos visualizar: ¿estructural?
¿cuantitativa? ¿de relaciones?
Puede leerse la totalidad del trabajo realizado en las entrevistas en el capítulo “Personas y Escenarios”
del anexo. En lo que afecta a Definición de problema, las entrevistas fueron extremadamente útiles para
detectar qué tipo de conocimiento, información, y datos interesaba a cada uno de los usuarios. Las conclusiones
se sintetizan en el diagrama de Venn que ilustra la página anterior.
Ya sabíamos para quién trabajábamos y, de alguna manera, qué se esperaba de nosotros.
“Y al principio fue el caos…”
La lluvia de ideas debe ser una de las técnicas de creatividad más conocidas, y su fama es merecida:
barata e inspiradora, nos permitía imaginar decenas de posibles problemas a visualizar con apenas
unos pósits. Hicimos una sesión de 10 minutos que generó una trentena de opciones; la hora siguiente
la dedicamos a entenderlas, profundizarlas, ordenarlas y clasificarlas. ¿Debíamos organizarlas por temas?
¿Por el posible formato de las visualizaciones? ¿Por nivel de complejidad?
Leímos, releímos y debatimos los problemas hasta darnos cuenta de que nuestro problema real era que
teníamos demasiados posibles problemas a resolver. Empezamos a imaginar una plataforma suficientemente
flexible para dar respuesta a todos: una visualización multipanel, interactiva, casi inteligente,
que permitiera cualquier tipo de consulta y ofreciera el gráfico perfecto para resolverla, que exportara
datos, que comparara, que te entendiera, que… ah, sí: que fuéramos capaces de convertir en realidad
en 6 semanas. Definitivamente, teníamos que conseguir centrarnos en un eje concreto. Había que simplificar.
25

2. Marcando los límites
¿Qué le interesa por encima de
todo a una empresa?
Narración visual ficticia (múltiplo
gráfico de evolución temporal)
entre los miembros del proyecto.
El pinganillo de Ricardo, omnipresente
en nuestras conversaciones
por Skype, es real.
26
Definiendo el problema
El diálogo que se muestra en esta breve tira cómica es ficticio, pero de alguna manera ese era el caldo
latente cuando optamos por sacrificar la mayoría de los problemas imaginados y enfocarnos en mostrar
las ventas y el margen de beneficios para cada producto.
Por una parte, nos era imposible resolver todo lo que nos habíamos planteado, y menos si queríamos
aportar algo de valor gráfico en el camino. Además, nos constaba que existían herramientas de Business
Intelligence en el mercado (ver annexo) que ya permitían multitud de consultas y que, sin embargo,
no estaban dando imágenes claras sobre aspectos básicos como la evolución de las ventas por familias.
Por otra parte, según las respuestas de nuestras Personas, su día a día les exigía ideas y números
claros a problemas muy concretos: ¿cuánto estamos vendiendo? (ventas), ¿cuánto estamos vendiendo
de este producto? (ventas por línea de producto, al detalle), ¿eso es más o menos que antes? (evolución
temporal y comparativa), ¿dónde se ha vendido? (información geográfica – por área de ventas). Habían
otros problemas, pero quedaban fuera de nuestras posibilidades: fuera por falta de datos (información
diaria) o capacidades (alarmas por clientes).
Tras horas de debates en múltiples plataformas, este fue el problema que esbozamos:
El problema
Visualizar las ventas y el margen de los productos de la empresa catalana de óptica para ayudar a detectar
oportunidades y reconocer patrones de negocio geográficos y de categoría.
Dominio de aplicación
España, un año dividido en meses y trimestres, todas las familias de producto.
Complejidad
Por provincias, por regiones, por equipo de ventas, por tipo de producto, por trimestre. Nos centraremos
en Valor Neto de la transacción y Margen de la misma (VEA)
Suposiciones
La tipología y las necesidades oculares de la población son homogéneas. Se usa el dato derivado de
ventas/población para mostrar diferencias.
Nunca nos habíamos alegrado tanto de tener, por fin, un problema.

3
se busca metáfora visual
De cómo dimos la vuelta al mundo para
encontrar una metáfora y finalmente
volver al punto de partida

3. Se busca metáfora visual
28
Pronto empezamos a trabajar en la definición de una metáfora visual única que, idealmente, nos serviría
de referente para el mapeo visual de todo el proyecto, tanto de la visualización final como de la documentación.
Una idea transversal que lo empapara y sustentara todo, dándole coherencia y claridad: un
tronco firme al que agarrarse.
Planta un árbol
En honor a la verdad, la metáfora del árbol estuvo encima de la mesa desde el principio. El día que nos
encontramos para hacer un brainstorming y empezar a esbozar una definición de problema, alguien habló
ya de árboles. Queríamos encontrar una manera de ver volúmenes de ventas que crecen o decrecen
en el tiempo, y a la vez, mostrar esa información para cada una de las posibles ramas de producto que
tenía la empresa…
¿Dijimos ramas? Sí: suponemos que la complejidad de la estructura jerárquica de productos del dataset
nos llevó muy pronto a intentar entenderla, visualmente, como un árbol ramificado. Al fin y al cabo los
árboles son, por naturaleza y tradición, una de las primeras maneras de representar familias de forma
gráfica. La metáfora es perfecta: un tronco común del que todo parte, que se eleva para ramificarse en
distintos tipos de producto que, aunque derivan de un padre común, toman distintas formas y valores.
¿Qué era nuestro dataset, sino un conjunto de valores para una familia de productos?
Pero a su vez, esos valores a representar no eran estáticos: teníamos información desglosada a lo
largo de un año, con todos y cada uno de sus meses. De entre todos los valores, habíamos decidido
centrarnos en los que nos parecían más relevantes para los usuarios: volumen de ventas en unidades
físicas, ventas netas y margen de beneficios. O en términos más conceptuales: queríamos representar,
por un lado, dos cifras absolutas, que podían crecer en una escala sin límites y que indicaban cantidad,
volumen, presencia del producto en el mercado; y por otro lado teníamos un porcentaje, que podía variar
pero siempre dentro de una escala cerrada (0-100%), y que de alguna manera representaba la calidad
de la venta de un producto concreto respecto a la calidad media del conjunto.
Teníamos, por tanto, valores dinámicos, que evolucionaban, pero que siempre hacían referencia a una
estructura estática y jerárquica. Necesitábamos una imagen gráfica que nos permitiera crear una estructura
fija y jerárquica, y que a la vez nos permitiera codificar sobre ella valores cambiantes. Es difícil
determinar cómo nuestras conexiones neuronales asociaron ese modelo abstracto con un árbol, pero la
idea estaba ahí: los patrones encajaban, y parecía que habíamos encontrado nuestra metáfora. El tronco
y las ramas podían representar la estructura de productos; el volumen de hojas, la cantidad de ventas, y
el color de las hojas, el margen de beneficio. Además, un árbol que florece o se marchita es una metáfora
orgánica inmediata que está más allá de cualquier codificación cultural específica: universalmente
comprensible sin necesidad de instrucciones, conecta directamente con nuestros instintos vitales, y…
Pero, alto: ¿un árbol que florece, en serio? ¿Qué tipo de gráfico es ese? ¿Lo has visto alguna vez en
Flowing Data? Y además: ¿habíamos encontrado una metáfora a la primera? ¿El primer día? De repente,
todo nos pareció una idea descabellada. Así que recogimos las hojas, las guardamos en un cajón, y decidimos
centrarnos en buscar alternativas.

3. Se busca metáfora visual
Isotipo / Sparkline ADN
Codificamos visualmente en un
único gráfico icónico los valores
de venta, coste y margen de un
producto, intentando crear una
imagen rápidamente identificable
para cada producto.
Exploratory Metaphora Analysis (EMA)
Entramos entonces en una fase errática en busca de la visualización perfecta que nos llevó a rastrear
blogs de todo pelaje, a revisar gráficos clásicos, perdernos en interactivos, repasar tablas de elección y
alumbrar ideas de todo tipo. Entre otros, contemplamos:
• Diagramas de relación, que nos permitieran ver la organización y complejidad de los productos
(familias, materiales, tratamientos) y su relación con su volumen de ventas.
• Matrices comparativas, para ver la relación entre las ventas de un producto y un vendedor.
• Heatmaps que nos permitieran codificar información geográfica sobre las ventas y los beneficios.
• Sparklines o Isotipos para codificar las ventas en el tiempo y ofrecer pequeñas gráficas de tendencia
que acompañaran a otros gráficos principales.
Entre las ideas barajadas, hubo una que desarrollamos más que el resto: el ADN de producto.
Un ADN económico
Inspirados en las Sparklines de Tufte, que grafican un concepto que luego puede ser utilizado dentro de
múltiples discursos, y en los isotypes de Otto Neurath, que se repiten a sí mismos lo necesario hasta
representar una cantidad determinada, pensamos en crear algo así como un icono visual para cada producto:
un DNI, un ADN, un gráfico propio que identificara económicamente un producto y lo diferenciara
del resto. Y no se trataba de inventar un símbolo al azar: queríamos crear ese ADN codificando los tres
valores que para nosotros más definían la esencia de un producto en el mercado: la familia a la que
pertenecía, su venta neta y su margen de beneficio.
¿Cómo codificar esos 3 datos? Pensamos en crear algo parecido a unas pequeñas piezas de Lego que
pudieran incorporar los 3 elementos. La familia es un elemento categórico: por lo tanto, siguiendo las
enseñanzas de Cynthia Brewer (o incluso el más purista Jacques Bertin), podíamos codificarlas con
distintos colores. Las ventas podían representarse con el tamaño de la ficha, y el margen, con el tamaño
de un rectángulo contenido dentro de la ficha acotado por el coste total: al fin y al cabo, el margen es un
tanto por ciento del total, lo que gráficamente puede entenderse como una porción de un todo.
Sin embargo, al plasmarlo visualmente, la simulación de un posible resultado del análisis nos convenció
que el output final sería demasiado cacofónico para poder extraer información útil de negocio.
29

3. Se busca metáfora visual
Gráfico Multipanel
Los primeros prototipos de multipanel
se enfocaron en intentar
encontrar un espacio en donde la
interactividad y el linked brushing
fueran posibles. ractividad reforzada
con Linked Brushing.
30
Multipanel: show them all
Algunos de esos gráficos cubrían con elegancia problemas parciales que habíamos descartado inicialmente,
haciéndonos replantear que quizá la visualización ideal debía ser multipanel: nos permitiría
ofrecer distintos gráficos que cubrieran todos los posibles problemas esbozados, y a la vez podríamos
trabajar en una navegación interactiva de focus & context y linked brushing, algo que parecía más que
deseable dada la cascada ingente de datos que se nos venía encima.
Sin embargo, ese linked brushing, que nos permitiría mantener la consistencia del producto a visualizar
(familia, subfamilia, región…) en los distintos paneles a la vez, ofrecía alguna complicación técnica. Así
que, manteniendo un ojo siempre clavado en el calendario, nos plateamos dos escenarios posibles:
• Ofrecer datos interactivos, atacando directamente a la BBDD según los campos que quisiera visualizar
el usuario, y graficar el resultado en tiempo real.
• Simular la interactividad con prototipos animados (Axure), y ofrecer algunos gráficos concretos
pre-generados como ejemplo.
El principal reto seguía sobre la mesa: ¿cómo integrar los distintos gráficos en un único multipanel
navegable?
Un Frankenstein y un Jackpot
A ver si consigo explicarlo.
Nos gustaba la metáfora del árbol porque nos permitía ofrecer simultáneamente, en un eje vertical con
su posible implicación jerárquica, información de distintos niveles de producto: genérica (familia), de
nivel intermedio (subfamilia) y de detalle (producto concreto).
Como no conocíamos un software capaz de hacer eso de manera orgánica y elegante, la propuesta que
surgió tras muchos debates fue crear un gráfico multipanel en el que se mostraran 3 paneles alineados
verticalmente: tres “cajas”, una encima de la otra, que mostraran 3 gráficos sobre los 3 niveles de la
familia de productos.

3. Se busca metáfora visual
Frankenstein + Jackpot
Combinación de una estructura
jerárquica vertical y temporal
horizontal.
De esta manera, manteníamos de alguna forma el concepto de “árbol” vertical que parte de un nivel
jerárquico más general y va creciendo especializándose en niveles jerárquicos inferiores. En cada nivel,
un gráfico distinto. Por eso lo bautizamos como el Frankenstein: porque era un gráfico multipanel que
en realidad mostraba información sobre una misma familia de producto. Era una unidad construida con
distintos gráficos/pedazos de puntos de vista.
Cada caja podía mostrar exactamente el mismo tipo de gráfico pero con diferentes campos, de más
agregado (abajo=tronco) a más desagregado (arriba=hojas). O bien podía mostrarse un tipo de gráfico
distinto en cada nivel, a conveniencia del usuario. ¿Qué tipo de gráficos podíamos ofrecer? No llegamos
a concretarlo mucho, pero podría ser una colección de gráficos sankey, o de treemaps, o…
En cualquier caso, ese Frankenstein vertical podía verse completado siempre por una estructura horizontal
que nos diera información de la evolución temporal: una especie de Jackpot que replicara en
3 cajas el gráfico de uno de los niveles, ofreciendo los datos para un período de tiempo distinto en cada
uno.
El resultado era una estructura en forma de T horizontal, que el usuario podría personalizar para crear una
historia tanto vertical (análisis y desglose en profundidad), como horizontal (análisis de secuencia temporal).
Este esquema, además, era suficientemente versátil como para funcionar en cualquier cultura, fuera
cual fuera su orden de lectura habitual (vertical u horizontal, de izquierda a derecha o de derecha a izquierda).
Bastaría con configurarlo para identificar en qué eje debe estar la línea temporal y en qué eje
la de profundidad, y mover los paneles a conveniencia.
Técnicamente, además, parecía relativamente sencillo incrustar gráficos en ese esquema. Cada gráfico
podía ser editable, de manera que el usuario elegiría tanto el tipo de gráfico como las variables que se
incluyen. Y a su vez, podía añadirse una opción para ver cualquiera de los minigráficos a pantalla completa
y ofrecer así una inspección más cómoda y detallada.
Sin embargo… ¿íbamos a ser capaces de generar esa inmensa colección de gráficos disponibles que parecía
pedir el proyecto? Estábamos volviendo a intentar crear una herramienta absolutamente flexible
que cubriera cualquier necesidad, que lo abarcara todo, dejando un escenario abierto, sin definir, sin
una orientación. En definitiva: estábamos dejando en manos del usuario el trabajo de identificar qué variables
le iban a aportar valor y, lo que era seguramente más arriesgado e injusto, le estábamos dejando
a él la responsabilidad de saber con qué tipo de representación gráfica iba a hallar una imagen que le
aportara conocimiento.
31

3. Se busca metáfora visual
Momento de Crisis
Demasiadas opciones sobre
la mesa.
32
En ese escenario, ¿qué papel jugábamos nosotros como teóricos, conceptualizadores y orientadores
gráficos? Decidimos que era prioritario reorientar nuestros pasos para ofrecer un foco claro.
Crisis, waffles y vuelta a las raíces
Ahora estamos en ese momento crítico que tienen todos los proyectos...
Ya lo verás por los mails.
Necesitábamos limpiar la mesa y tomar una determinación en firme para empezar a trabajar. Y, a ser
posible, una determinación que fuera técnicamente factible, visualmente correcta y empresarialmente
útil. Y fue en ese estadio de angustia creciente donde, casi en sueños, una noche se nos apareció el
Wafflegram.
Nuestra propuesta de Wafflegram fue un intento de simplificación y foco ante todo el ruido que habíamos
generado. Se trataba de mostrar las ventas de cada familia de subproductos por provincia a través
de waffle charts: rectángulos compuestos de pequeños cuadrados que codificaran un volumen de venta
fijo.
Un Waffle no deja de ser una versión revisada de un gráfico de barras en la que la célula individual que
compone el waffle tiene un sentido económico que puede ser útil para el analista (p.ej. 100m € de ventas
o beneficios) pudiendo llegar a mostrar datos contextuales de cada una de esas células (p.ej. geografía
a la que pertenece esa venta).
La longitud del rectángulo codificaría el volumen de venta; el color del cuadrado, el trimestre en que se
había producido. Los waffles conformarían una tabla en la que en el eje vertical se situaran las provincias,
y en el horizontal, las familias.
Previmos dos tipos de ordenaciones, para ayudar a la comparativa: una ordenación alfabética de las
provincias, para buscar casos concretos más fácilmente, y una ordenación de mayor a menor volumen
de ventas.
Para añadir valor, propusimos calcular un dato derivado que no se encuentra en el dataset: la desviación
absoluta respecto el valor estadístico esperado (si ambas variables fuesen independientes). La cifra de

3. Se busca metáfora visual
Wafflegram
Gráfico catártico que pretendía
ser simple a la par que útil para
el analista
venta esperada para cada producto en cada provincia se calcula teniendo en cuenta el porcentaje de
ventas sobre el total que representa ese producto, y el porcentaje de ventas sobre el total que tienen
lugar en esa provincia. Con esas dos cifras de referencia, se puede deducir cuál sería el porcentaje estadísticamente
esperado de ventas de ese producto en esa provincia: lo previsible.
Valor esperado= % total fila x % total columna x Suma total de las ventas (o el margen) ->Ej: %ventas
Área Sur x % ventas Progresivos x Ventas Totales
Si resulta que en realidad las ventas son sensiblemente mayores o menores a ese porcentaje, significa
que existe alguna correlación específica entre esa provincia y ese producto que está afectando a las
ventas, para bien o para mal.
Se trata del mismo principio que, en la última parte del reciente proyecto de Moritz Stefaner, se usa para
reflejar relaciones entre ingredientes de muesli superiores a las esperadas en función de la presencia
de cada ingrediente por separado. http://moritz.stefaner.eu/projects/musli-ingredient-network/
Creíamos que ése era un camino útil y posible y, como tal, lo llevamos a audiencia en una de las presentaciones
parciales del proyecto, junto al árbol, el ADN y el Frankenstein / Jackpot y. Y allí, al exponer las
opciones ante el público, empezaron a aparecer nuevos argumentos que no habíamos tenido en cuenta
los últimos días.
Entre todas las opciones gráficas, el árbol era el que parecía entenderse inmediatamente, de manera
natural, sin necesidad de explicaciones ni aprendizaje específico: la descodificación de la vitalidad de
las distintas ramas era inmediata, y el mensaje no ofrecía ambigüedades. Además, parecía que la originalidad
del gráfico aportaba un valor académico; si las dificultades técnicas no nos permitían hacerlo
totalmente funcional, al menos habríamos desarrollado un nuevo modelo que podía ser pulido y perfeccionado
con el tiempo. Ciertamente, limitaba el tipo de datos que íbamos a poder generar, pero aunque
fuera parcial, cubría satisfactoriamente la definición de problema que nos habíamos propuesto: ayudar
a detectar patrones en las ventas y márgenes de los distintos productos.
Así que descartamos el resto de opciones y volvimos de nuevo a las raíces.
33

3. Se busca metáfora visual
34

4
codificación visual
O la explicación razonada de porqué,
milagrosamente, los datos cobran vida en
forma de árbol

4. Codificación visual
36
La elección del árbol como metáfora orgánica era original en la misma medida que arriesgada. Construir
algo de cero es una oportunidad para definir un nuevo modelo que se acerque más que ninguno
previo a lo que uno aspira; o al menos, que se le acerque de una manera distinta, novedosa, que colabore
a construir conocimiento. Sin embargo, esa misma oportunidad implica que el reto es mayor: no hay
documentación, no hay código, no hay modelos a los que evaluar y tomar como referencia; no existe una
base de trabajo hecha sobre la que auparse y tomar impulso. Aún así, la posibilidad de definir un modelo
a medida, aunque fuera de manera teórica y aproximativa, nos parecía que aportaba valor y que sería un
buen ejercicio para testear nuestros conocimientos.
Valores y atributos: baile de parejas
Lo de las proporciones y eso... tú mismo... 'que queden naturales a la par que chic'.
Teníamos esa idea general de que nuestra metáfora base debía ser un árbol: un elemento orgánico, con
una estructura y un comportamiento fácil de comprender en todos los ámbitos y culturas. Y sabíamos
que queríamos codificar la vitalidad de las ventas de la empresa catalana a través de la vitalidad de ese
árbol metafórico: el árbol debía parecer más vivo cuanto más vivas fueran las ventas y los beneficios.
Valores
Así que nos pusimos a listar los posibles valores que nos parecía interesante codificar para cada producto,
y concluimos:
Valores numéricos:
• Unidades vendidas (UNF)
• #SKUs (o referencias)
• Venta neta (VN)
• Margen de beneficio (VEA)
Valores categóricos:
• Material
• Foco
• Tratamiento
• Marca
Valores temporales:
• Evolución temporal
Valores geocodificados:
• Distribución geográfica por provincias
Variables numéricas derivadas:
• Ventas/Margen per cápita
• % margen (VEA/VN)
• % ventas o margen sobre total Ventas
Algunos eran datos numéricos (UNF, VN, VEA) y otros categóricos (material, foco, tratamiento, marca),
y lo que estábamos pretendiendo mostrar, en realidad, eran las relaciones entre ambos.
Sabíamos que además querríamos mostrar esas relaciones cruzadas con otras dos dimensiones: la
temporal y la geográfica, que se superponían transversalmente sobre todos los datos. Fuera la que
fuera la manera en que visualizáramos los valores de ventas, unidades y márgenes para las distintas
categorías de productos, teníamos que encontrar la forma de ofrecer esa imagen para distintas geografías
a la vez y para distintos períodos de tiempo a la vez. Había que permitir la comparación temporal y
espacial.

4. Codificación visual
Esbozos iniciales.
Posible matriz codificando el volumen
de ventas en cada región
según el tipo de foco.
Atributos
Para listar los atributos, empezamos por dibujar un árbol que nos permitiera identificar con claridad los
atributos visuales con los que podíamos contar. Ésta fue la lista:
• Longitud tronco
• Grosor tronco
• Longitud rama
• Grosor rama
• Orientación de la rama (grado de inclinación respeto un eje plano)
• Posición de la rama en la copa (arriba-abajo, izquierda-derecha, secuencia de ordenación…
¿podríamos definir cuadrantes interpretativos?)
• Subniveles de ramas (tronco – rama principal – subrama 1 – subrama 2)
• Distribución de las ramas a lo largo del tronco (tipo candelabro, tipo pino, tipo arbusto)
• Número de hojas
• Tamaño (área) de las hojas
• Ubicación de la hoja en la rama (lado superior|inferior, lado izquierdo|derecho)
• Color de las hojas
• Movimiento / pulso hojas
¿Cómo mapear valores y atributos de manera que tuvieran sentido? Otros antes que nosotros se habían
planteado el gran dilema, así que acudimos a los clásicos: Bertin & Brewer. Con sus tablas y conclusiones
en una mano y el árbol y el dataset en la otra, construimos una serie de bocetos iniciales, explorando
las posibles codificaciones.
Datos categóricos
• Material
• Foco
• Tratamiento
• Marca
• Subniveles de ramas
• Distribución de las ramas a lo largo del tronco
• Posición de la rama en la copa
Teníamos cuatro datos categóricos que determinaban a qué grandes conjuntos pertenecían nuestros
productos: ¿de qué material estaban hechos?, ¿qué foco tenían?, ¿qué tratamiento?, ¿a qué marca pertenecían?
La clasificación de los productos en estos grupos generaba una jerarquía de subconjuntos
relativamente compleja, cada uno con sus datos correspondientes, y de ahí había nacido nuestra idea
de estructurar los datos en un elemento que nos permitiera hacer ramificaciones representando esa
jerarquía.
37

4. Codificación visual
Ilustración candelabro vs. pino
La ilustración muestra cómo crecerían
las ramas en el espacio
con dos tipos de distribuciones
diferentes. El espacio que corresponde
a cada uno de los subniveles
jerárquicos se distribuye
verticalmente en el candelabro y
horizontalmente en el pino.
38
De tal tronco, tal rama
El árbol suele partir de un tronco central (el nodo padre) que se va ramificando en un primer nivel (nodos
hijos) que pueden tener un tercer y cuarto nivel de subramificación (nodos nietos y bisnietos). Parecía
natural, entonces, que codificáramos la pertenencia a estos conjuntos mediante los distintos niveles y
subniveles de las ramas.
Distribuciones
Nos planteamos si nos convenía más una distribución tipo candelabro, en la que ramas de un mismo
nivel jerárquico nacen todas a la misma altura (la jerarquía se define verticalmente) o una distribución
tipo pino, en la que ramas de un mismo nivel jerárquico se distribuyen a lo largo del tronco para ramificarse
expansivamente (la jerarquía se define horizontalmente). El pino podía ayudarnos a distribuir
mejor los elementos en el espacio y evitar aglomeraciones en la copa, pero a efectos de comparación,
la verticalidad ofrecía un eje común en el que resultaba mucho más sencillo comparar productos de un
mismo nivel.
Sin embargo, habiendo aceptado que la ordenación jerárquica nos permitiría hacer comparativas de
grandes conjuntos y de productos determinados a la vez, la duda asaltaba de nuevo. ¿Cuál debía ser el
orden de esa jerarquía? La realidad era que la estructura de los datos no encasillaba a unos nodos a ser
padres y a otros a ser hijos. El hecho de que casi todos los productos tuvieran definido un valor para cada
categoría, significaba que podíamos ordenar la jerarquía de diferentes maneras: podíamos partir de la
clasificación por materiales, para después ramificar por foco y subramificar por marca; o partir de la
clasificación por marcas, para ramificar por materiales y subramificar por foco; o… Las combinaciones
eran múltiples, y todas parecían poder aportar valor a la comprensión. Eso nos hizo concluir que la jerarquía
del tronco y las subramificaciones no podía ser fija: teníamos que permitir al usuario escoger
qué quería colocar en cada uno de los niveles.
El sentido del orden
Por último, nos planteamos si sería interesante ordenar las ramas con algún criterio específico en su
distribución de izquierda a derecha. ¿Podíamos codificar de alguna manera la posición en el espacio? Si
ordenábamos las ramas según el volumen de ventas, por ejemplo, sería mucho más fácil compararlas y
saber qué producto estaba consiguiendo más beneficios. Si conseguíamos añadir alguna otra dimensión
vertical para determinar las alturas, podíamos incluso acabar definiendo un cuadrante interpretativo,
que nos permitiera reconocer el comportamiento de un producto según su posición en él…

4. Codificación visual
Pero la altura de las ramas ya estaba codificando una jerarquía, y cambiar el criterio parecía boicotear el
resto de decisiones tomadas sin un objetivo claro. Para más inri, nos dimos cuenta que si ordenábamos
siempre automáticamente la posición de las ramas de izquierda a derecha según sus beneficios, cuando
intentáramos ver la evolución anual o hacer comparaciones mes a mes, la re-ordenación iba a traernos
problemas: si la rama de “producto” cambiaba de lugar, estando identificada “sólo” por una etiqueta,
sería fácil que un producto se moviera de sitio de mes a mes y no percibiéramos el cambio, dando lugar
a malentendidos. Optamos pues por descartar la posición como una forma de ordenar por beneficios, y
decidimos dejarla fija como una manera de identificar un producto de forma estable.
Datos numéricos
Teníamos claro que 2 de los valores numéricos absolutos con los que jugábamos, las unidades vendidas
(UNF) y el volumen de venta neta (VN), tenía sentido codificarlos con atributos visuales relativos a tamaño,
o bien generar isotipos: iconos visuales que representaran uno de los elementos y se repitieran
hasta representar la cifra deseada. Básicamente teníamos:
• Venta neta (VN)
• Unidades vendidas (UNF)
• Longitud tronco
• Grosor tronco
• Longitud rama
• Grosor rama
• Número de hojas (nuestros isotipos particulares)
• Tamaño (área) de las hojas
• Movimiento / pulso hojas
La fuerza representativa de un isotipo
Teniendo en cuenta que lo que más define la vitalidad “natural” de un árbol es el volumen de su follaje
(y el color, pero de momento nos centrábamos en tamaños), y lo que da una idea más cercana a la salud
de las finanzas de la empresa catalana son sus ventas netas, nos pareció que utilizar las hojas como
isotipos para representar el volumen de la venta neta era una buena idea. Más hojas, más volumen de
ventas. Sería una imagen clara, inmediata y coherente, que daría un contexto excelente. Éramos conscientes
que el número de hojas debía ser a escala, y que sería difícil contar las hojas de las respectivas
ramas para hacer comparativas, pero pensamos que podríamos solucionar los problemas de focus añadiendo
etiquetas con las cifras concretas cerca de las hojas, o en alguna tabla adyacente.
La alternativa para facilitar comparaciones de las hojas –y evitar posibles solapamientos- podría ser
fijar el número de hojas y codificar la venta neta según el tamaño de éstas. Hoja más grande, venta
más grande. Pero los isotipos iban a generar una imagen más parecida a un árbol real, así que lo descartamos.
Márgenes delicados
El margen de beneficio (VEA), sin embargo, nos generaba alguna duda. Si bien era un valor numérico,
podíamos contemplarlo como un valor absoluto (el total de beneficio obtenido, en euros), o bien como
un valor relativo (el porcentaje de beneficio obtenido, respecto al total de la venta). Este producto me
genera ¿3.000 euros de beneficios?, o ¿un 20% de beneficios? O incluso haciendo algún cálculo más: el
margen de beneficios que me genera este producto, ¿está por encima del margen medio del conjunto?
Es decir, ¿estoy ante un producto que me da un margen comparativamente interesante?
¿Cuál de esos indicadores podía aportar más valor a la comprensión? Nos pareció que el porcentaje era
más significativo de la “calidad” de venta del producto: si lo que pretendíamos era encontrar patrones
transversales y evaluar los productos por el papel que jugaban en el conjunto de las ventas, el margen
39

4. Codificación visual
Tabla de colores divergentes
Paletas de colores válidos para
categorizaciones divergentes,
según las consignas de Cyntia
Brewer. Las paletas son generadas
por la macro BREWERPAL,
para R.
Vídeo de árbol con hojas en movimiento
(efecto pulso)
El movimiento o pulso de las hojas
en zonas específicas o en todo
el árbol podría representar información
relacionada, por ejemplo,
con el número de transacciones
asociadas a esa familia o subfamilia
de productos.
http://youtu.be/zb_8WN9woy8
40
“comparativo” es el que permitiría una comparación inmediata más clara con el resto de productos, sin
necesidad de que el usuario “reescalara” una cifra absoluta (ya se la estábamos escalando nosotros
previamente). Así que optamos por priorizarlo, sin descartar de momento dar alguno de los otros dos
valores posibles relacionados con el margen.
La cuestión era: ¿cómo íbamos a codificar un valor que reflejaba si el producto se encontraba por encima
de la media reinante o por debajo? El sistema de color de Smartmoney se nos apareció como un
hermano gemelo con la respuesta bajo el brazo: podíamos codificarlo con una escalera bicolor, que
oscilara hacia dos extremos desde un punto de equilibrio neutro, que sería el margen medio. En Smartmoney
se ofrecen el rojo y el verde como extremos de la escala, aunque existe la opción de mudar a una
codificación a amarillo y azul en caso de problemas con la detección de color. Brewer apoyaba la codificación,
que según su clasificación sería una bipolar o divergente, así que aceptamos la codificación
definitivamente. (optando por una gradación de verde a rosado, en lugar de amarillo azul, para manter
la organicidad).
Temblores ocasionales
En algún momento consideramos la posibilidad de utilizar el movimiento de las hojas (como si una suave
brisa capitalista las meciese) para indicar el volumen de transacciones que tenían lugar en una rama
concreta de producto, o bien para codificar una variación drástica en el comportamiento de ventas, si
ésta tenía lugar. El movimiento actuaría como una alarma selectiva para atraer la atención. Sin embargo,
la complejidad de programar algo así nos hizo desestimarlo pronto.

4. Codificación visual
Matriz ventas regionales
Posible matriz codificando el volumen
de ventas en cada región
según el tipo de foco.
Dimensión geográfica
La información geográfica parecía que tenía que ser codificada, por naturaleza, en un mapa. Sin embargo,
¿tenía tanta relevancia el espacio físico concreto en los datos sobre ventas por provincias? Nos
planteamos hasta qué punto teníamos que priorizar la posición geográfica de las distintas provincias
(conocidas sobradamente por los usuarios potenciales). ¿No se trataba, en realidad, de una información
básicamente categórica? Teníamos unos datos de ventas agrupados en unas categorías, que en este
caso eran provincias. Lo que nos interesaba destacar no era la posición de esa categoría en un mapa
geográfico, sino el volumen de las unidades, los beneficios o los márgenes obtenidos en esa categoría
específica. ¿Qué tipo de gráfico estábamos buscando, entonces?
Evaluamos la posibilidad de incluir la variable geográfica como una “semilla” más a partir de la cual
construir el árbol. Sin embargo, el número de categorías existentes generarían igual número de ramas:
demasiadas para un solo árbol. El peligro de solapamiento era evidente, y la comparación iba a resultar
imposible. Si queríamos dar un gráfico con la variable geográfica, tenía que ser un gráfico al margen
del árbol.
¿Cómo íbamos a ofrecer esa información geográfica? ¿Con qué datos? ¿Con qué forma? Una aproximación
posible era realizar una matriz que cruzase productos y geografías. No obstante el número de
provincias es muy elevado (52) y las matrices tienden a saturarse.
Queríamos ser consistentes y mantener el foco en los dos valores que reflejábamos en los árboles: venta
neta y margen. Finalmente optamos por ofrecer un mapa de España, generado con Geocommons, sobre
el que se pueden visualizar ambos datos: círculos con un área correspondiente al valor de la venta en
aquella provincia (normalizada con la población), y un heatmap que codifica a través del color el porcentaje
de margen respecto a la media. Manteniendo los atributos de tamaño de círculo y color entre
el árbol y el mapa nos parecía que, de alguna manera, prolongábamos la metáfora y ayudábamos a la
comprensión inmediata y las comparaciones.
DIMENSIÓN TEMPORAL
• Orientación de la rama (grado de inclinación respeto un eje plano)
Para representar la evolución temporal, tratándose de un árbol, nos parecía que lo más coherente y
fácil de entender de manera instintiva sería una animación del propio árbol: añadir un botón de play que
41

4. Codificación visual
Ilustración estaciones ventas
Ilustración que muestra aspectos
simulados de distintos árboles,
según el volumen de ventas generado
en esa categoría en un
momento determinado. La organicidad
de la metáfora permite
asociar rápidamente los aspectos
visuales con la realidad de los
datos.
Línea de botones
Que nos permite acceder directamente
a los resultados de cada
uno de los meses, con un solo
clic.
Detalle de esbozo
En nuestros ejercicios de sketch
to think evaluamos la codificación
de tendencias temporales según
la inclinación de las ramas respecto
a su base.
42
hiciera evolucionar al árbol a lo largo del año, mostrando secuencialmente la imagen correspondiente
a cada mes, como si de una película se tratase. Así podría verse la evolución orgánica: en que ramas
aparecían nuevas hojas, qué meses eran más verdes, cuándo desaparecían líneas de ventas… Si la dimensión
temporal realmente tenía afectación sobre las ventas –y estábamos convencidos de que así
era-, podrían incluso detectarse “estaciones” de ventas según las imágenes de los árboles resultantes.
Sin embargo, la idea de la animación, aunque atractiva, ofrecía problemas para comparar períodos de
tiempo no consecutivos. ¿Cómo recordar la imagen de febrero cuando lleguemos a noviembre? Era
imperativo poder ofrecer una vista directa de cada uno de los meses a voluntad: la imagen fija con el
sumatorio de cada mes. Acordamos dar acceso directo a cada uno de estos árboles, añadiendo, por
ejemplo, botones para cada uno de ellos debajo del árbol.
Y aún así, ninguna de estas dos soluciones resolvía un tema esencial: poder tener una imagen única con
la evolución temporal de los valores. Tanto la animación como la vista directa del mes ofrecían sólo, en
cada momento, una imagen parcial de los datos: un árbol concreto. Valoramos la posibilidad de codificar
la tendencia de ventas de un producto concreto a partir del ángulo de inclinación de la rama sobre un eje
transversal imaginario que se situaría en la base de su nacimiento: aquellas ramas que se inclinasen en
un ángulo entre 0º y 90º, denotarían una evolución positiva; las que lo hiciesen en un ángulo entre 90º y
180º, denotarían una evolución negativa.

4. Codificación visual
Gráfico de líneas
El gráfico mostrará la evolución
anual del valor seleccionado,
para cada uno de los árboles resultantes
según la semilla seleccionada.
Pero esta aproximación tenía un hándicap: no había un único nivel de ramas, sino que hay subramas que
brotan de ramas previas. Cuando las ramas previas ya tienen una inclinación, la interpretación angular
de la subrama que surge de ella se complica.
Y además… una evolución positiva o negativa, ¿respecto a cuándo? ¿Respecto al último mes? ¿Respecto
al último trimestre? ¿A lo largo del año? No acabábamos de ver la manera de que quedara claro, y
finalmente consideramos que, para una evolución temporal de valores que nos diera un contexto claro
para todo el año, lo mejor era incorporar un gráfico de líneas fijo a pie de árbol que nos sirviera en todo
momento de referencia.
Últimos ajustes
Simplificación del follaje
Evaluado de cerca con una mirada técnica, el conjunto parecía plausible, a excepción de un punto: las
hojas. El fantasma de la imposibilidad de programar algo semejante se cernía sobre nosotros como una
sombra incómoda, generando una tensión obvia entre lo que imaginábamos y lo que sospechábamos
que podría ser posible: habíamos escuchado suficientes advertencias sobre las dificultades técnicas de
trabajar con gran cantidad de objetos y el alto riesgo de solapamiento que suponían. Por precaución,
hicimos un ejercicio de simplificación, intentando reconvertir las isotópicas hojas en una única entidad
que, con su tamaño, denotara lo mismo que iban a denotar todas las hojas de una rama juntas: la venta
neta. Nos basamos en el ejemplo provisto por la visualización arbórea de Bocoup sobre los currículos
de Linkedin y elaboramos el siguiente modelo:
Así fue como nuestras hojas se transformaron en copas.
43

4. Codificación visual
Diagrama copas
Diagrama esquemático con anotaciones,
en donde se muestra
cómo el concepto de hojas repetidas
formando una masa cuantificable
es sustituido por un único
círculo cuya área codifica cantidades.
Tabla de atributos
Caracterización de los posibles
tipos de árboles resultantes, que
permite una interpretación rápida
de qué está sucediendo con
las ventas.
44
Árboles con carácter
Si aplicábamos esta codificación, nos dimos cuenta que pronto empezaríamos a tener árboles con morfologías
diferentes para cada tipo de producto, como si de caras de Chernoff forestales se trataran.
Podríamos identificar “caracteres” de venta según la morfología de su tronco (o ramas) y su follaje
asociado:
Sabíamos qué íbamos a mostrar, sólo nos faltaba encontrar el cómo.

5
definiendo la interacción
O de cómo luchamos hasta la extenuación
para conseguir un paper-, axure-,
illustrator- o lo que fuera -prototype

5. Definiendo la interacción
46
Había dos factores prioritarios que tenía que cubrir la interacción: ofrecer flexibilidad en la elección y la
ordenación de las categorías de productos a mostrar, y ofrecer focus & context: dar una imagen general
y permitir a la vez una indagación en el detalle. Asimismo, queríamos mantener de alguna forma el look
& feel arbóreo en todos los elementos, para darle consistencia a la metáfora (e intentando no caer en
el infantilismo).
Con esas ideas en mente, empezamos a trabajar en varios prototipos; algunos primeros esbozos en
papel, otros animados en Power Point y finalmente algunos construidos con Axure, con la idea de poder
programar y comprobar la interacción y hacer unos test de usuarios lo más realistas posibles (ver “Prototipos”
en los anexos).
Sabíamos que si no podíamos programar los árboles tal como los habíamos definido, al menos podríamos
hacer una prueba de concepto interactiva para validar –o no- el modelo.
El camino de la navegación
En una visualización interactiva, donde el usuario debe realizar algún tipo de acción sobre los objetos
para conseguir visualizar lo que desea, teníamos que asegurarnos que las posibles interacciones quedaban
debidamente claras.
En nuestro caso, para generar los árboles el usuario debe elegir, obligatoriamente, un criterio de ordenación:
una categoría madre o semilla, a partir de la cual se establecerá la ordenación, y luego la jerarquía
que deben seguir las ramificaciones subsiguientes. También tiene que indicar qué tipo de variable
desea ver reflejada en el área definida por las copas de los árboles o de las ramas (Venta Neta, Margen
o SKUs) y, por último, para qué período de tiempo. Tres elecciones antes de generar una visualización:
tres pasos a dar antes de llegar al árbol.
¿Cómo indicarle el camino? Manteniendo la metáfora orgánica, nos pareció que debíamos simular de
alguna manera un recorrido terrenal, un camino que avanzara paso a paso hasta conducir al árbol.
Utilizamos la horizontalidad de la pantalla para crear esa línea narrativa: empezando por la izquierda
(siguiendo el orden de lectura occidental), el camino a seguir es indicado con una flecha, que nos indica
paso a paso qué decisiones debemos tomar.

5. Definiendo la interacción
Selección de variables
Ya teníamos una base. ¿Cómo visualizar la selección de variables?
Para ser consistentes con nuestra metáfora y nuestra codificación de las categorías como tronco – ramas
que crecían a partir de una de las categorías en concreto, parecía lógico considerar que esa categoría
madre desde la que las otras se abrían podía ser considerada una “semilla”.
Siguiendo con el paralelismo orgánico, para hacer crecer y explorar un árbol de producto concreto, el
usuario debía escoger una semilla madre y lanzarla al espacio adecuado: la base del árbol. Como queríamos
que el orden en que se ramificaban los productos también fuera elegido por el usuario, parecía
lógico que le permitiéramos escoger así qué categorías se injertan en el tronco o en las ramas para
conformar el segundo y tercer nivel de ramificaciones.
Para hacer el proceso lo más sencillo posible, pensamos en olvidarnos de desplegables y selectores y
colocar, directamente, un botón o “pieza” para cada una de las categorías elegibles: queríamos mostrarlas
todas, accesibles directamente sin entrar a consultar listados. En el ideal, la pieza sería seleccionada
con un clic mantenido, y arrastrada por el usuario a la posición de la estructura del árbol donde
le interesara colocarla. El drag&drop imitaba el gesto biológico de escoger y dejar caer una semilla
en un lugar receptor.
Para facilitar la tarea, nos propusimos diseñar los botones y los lugares receptores o “contenedores”
con formas específicas que denotaran dónde podía encajar cada pieza, si es que había alguna restricción.
Queríamos usar lo que en diseño se ha venido a llamar affordances & constraints, o lo que, de una
manera más elemental, conocimos todos de niños con el juego de encajar las piezas según sus formas.
47

5. Definiendo la interacción
48
Selección temporal
En el gráfico de evolución que se ofrece a pie de bosque aparece una línea distinta para cada árbol que
se está visualizando, con el objetivo de facilitar la comparación de los distintos árboles en el tiempo,
que de otra forma resultaría complicada. Sin embargo, según la semilla escogida, el número de árboles
generados puede crecer considerablemente, a la par que el número de líneas del gráfico de evolución.
Para evitar el solapamiento en esos casos, se añadió un radio button en el que el usuario pueda escoger
qué líneas quiere ver.
El acceso a los datos de cada mes se hace directamente seleccionando el mes en una línea de botones,
pero también puede utilizarse la franja amarilla situada sobre el gráfico, deslizándola a lo largo del
calendario para una visualización más rápida e intuitiva.
Interacción en los árboles: focus&context
Nuestros árboles parecían prometer una visión rápida y luminosa del contexto de ventas de la empresa.
Sin embargo, ¿podíamos conformarnos sólo con ese mapa biológico general? Nos parecía imprescindible
poder entrar a detalle y ofrecer información que incluyese, sobre todo, las cifras concretas y un
insight en los datos geográficos.
Estuvimos buscando y rastreando opciones interactivas para dar contexto y foco a la vez, y encontramos
algunos ejemplos que nos podían servir de base. El patrón era similar en todos: se mostraba a primera
vista la estructura general, fuera un mapa, un diagrama radial o un calendario rectangular anual; lo
importante era que se viera en su integridad. Para acceder al foco, el usuario clicaba sobre uno de los
elementos: a partir de ahí, el comportamiento para dar el foco variaba. Estas fueron algunas de las opciones
que encontramos:
• Reorganización. El elemento pasa a situarse en el centro de la visualización y el resto de contenidos
se estructuran a su alrededor, redimensionándose si es necesario (Inside the Courts, The
Guardian).
• Multipanel. Se ofrece la información ampliada en un panel situado al margen (2011, The Year in
Review, The Guardian).
• Zoom. Nos planteamos la opción de hacer zoom para acercarse al detalle de una zona concreta,
pero en este caso, nos gustaba la idea de poder mantener a la vez el foco y el contexto.
Finalmente, optamos por dar algunas cifras directamente como etiqueta en la visualización. Al hacer
un clic, ofreceríamos una ficha conteniendo todas las variables de aquél nodo. Para la información geográfica,
probamos la opción de reorganizar las copas generando un círculo para cada provincia, pero el

5. Definiendo la interacción
2011 – The Year in Review. The
Guardian.
Un ejemplo de foco ofrecido a través
de multipanel.
http://www.guardian.co.uk/
news/datablog/interactive/2011/
nov/28/court-sentencing-magistrates-crown
Inside the courts: what happens
to defendants, visualized. The
Guardian.
Un ejemplo de foco ofrecido a través
de reorganización.
http://www.guardian.co.uk/
news/datablog/interactive/2011/
nov/28/court-sentencing-magistrates-crown
resultado nos pareció innecesariamente confuso. Así que optamos por generar un panel paralelo que se
genera (a doble clic) al hacer clic sobre la opción del tooltip con el resumen de los datos sobre cualquiera
de los elementos, y que es ampliable a pantalla completa. Además, había que ofrecer botones para
cerrar esa información emergente.
En ambos casos, nos pareció prudente añadir un texto discreto explicitándole al usuario qué debía hacer
para acceder al foco, como en el ejemplo de The Guardian: “Click on the bubbles to see how many people
go through each stage of the justice system”.
49

5. Definiendo la interacción
Menús del prototipo
(1) Pasos para construcción
del árbol
(2) Gráfico temporal
(3) Gráfico principal
(4) Menús de navegación
Nivel 1 de desglose del árbol
(VN | n árboles con 1 copa)
Una vez seleccionado el primer
nivel de semillas, junto al valor
y el momento del tiempo a visualizar
se desplegarían un número
de árboles iguales al número de
opciones presentes en la semilla
escogida. La altura del tronco
representa siempre la variable
UNF. El área de cada círculo es
proporcional, en este caso, a las
VN y su color al % de margen de
esa familia.
50
El camino de regreso
Toda exploración avanza con más valentía si sabe que sus pasos tienen vuelta atrás, si tiene un lugar al
que regresar. Para dar libertad de interacción real, teníamos que ofrecer a nuestros futuros usuarios
esas dos bazas: una vuelta a casa, al punto de partida, en donde se desandaran todos los pasos dados;
y una opción menos drástica que permitiera dar tan sólo un paso atrás, un CTRL+Z que permitiera
reorientar el camino. De ahí la presencia de los botones “Home” (icono árbol) y “Atrás” (icono flecha) en
nuestros prototipos.
Recorridos simulados
Los prototipos finales de nuestra visualización pueden verse en http://goo.gl/isl3e. En este capítulo
ofrecemos algunas imágenes representando posibles recorridos que muestran algunas interacciones y
el resultado que se deriva de ellas.

5. Definiendo la interacción
Nivel 1 de desglose del árbol
(VEA | n árboles con 1 copa)
Alternativamente se puede seleccionar
la variable VEA (margen
absoluto).
Nivel 2 de desglose del árbol
(VN | n árboles con copas al
segundo nivel)
A medida que desglosamos
la información introduciendo
nuevas variables que se
injertan en el tronco podemos
ver cómo las áreas previas se
subdividen y muestran familias
de productos con distintas
relaciones entre ventas
en unidades, en valor y en %
de margen. (Ver análisis de
negocio para más detalle)
Nivel 3 de desglose del árbol
(VN | n árboles con copas al segundo
nivel)
Despliegue de los árboles por
las 3 semillas, en este caso
foco->material->marca lo
que permite ver a nivel más
granular la composición de
las ventas y los nichos de
margen.
51

5. Definiendo la interacción
Datos geolocalizados de
VN (círculos)
Si queremos más detalle de
una familia (copa del tronco o
de una rama) concreta podemos
acceder a información de
sus ventas (o margen) a nivel
geográfico. Aquí burbujas
proporcionales a VN. Software
usado: Geocommons.
Datos geolocalizados de
VN x cápita (color)
Igualmente podemos visualizar
las variables derivadas
(ratio VN o VEA x cápita, %
sobre ventas totales en cada
provincia) en una escala
cromática secuencial.
Leyendas
Un botón lateral nos permite
consultar en todo momento la
leyenda, que ayuda a descodificar
el valor del área de las copas y el
valor del margen representado
por el color. A clic, la leyenda desaparece
para no ocupar espacio.
52

6
tests de evaluación y usabilidad
Veo, veo… ¿qué ves?

6. Test de evaluación y usabilidad
Diagrama heurístico de Infovis
Un diagrama que nos ayuda a
identificar qué aspectos o categorías
de la heurística hay que evaluar
en cada fase del diagrama de
Infovis. O, en otras palabras, qué
hemos de asegurarnos que estamos
haciendo correctamente
en cada fase del proceso visualizador.
54
Primeros pasos para una heurística de la visualización
En la sesión de usabilidad con M.C. Marcos habíamos tenido conocimiento de la existencia de un tipo de
test de evaluación que suele aplicarse a las páginas web para asegurar que cumplen con los requisitos
de accesibilidad y usabilidad estándares del mercado. Es el conocido como “Modelo heurístico” o “Heurística”:
en la práctica, se trata de un Excel con cuestiones clave, organizadas por temas, a las que hay
que responder. Las preguntas permiten identificar la existencia de problemas y, de haberlos, se juzga
también su severidad en función de su frecuencia y el impacto sobre la navegación. Es preciso que la
evaluación la realicen distintos usuarios (entre 3 y 5, se recomienda), para que el juicio sea equilibrado.
Este modelo heurístico es ampliamente usado por la comunidad de expertos en usabilidad en la primera
fase de evaluación de unos prototipos o de una web: sirve como filtro inicial para detectar los errores
más patentes. Una vez pulidos, en la segunda fase de evaluación ya se pasa a hacer pruebas más específicas:
recorridos cognitivos (con perfiles de personas / escenarios) y self-reported metrics. Esos
test permiten tanto detectar los posibles problemas que pueden darse en la consecución de una tarea
concreta, como evaluar el grado de satisfacción que genera la experiencia en el usuario.
Heurísticas y tests de usuario: herramientas altamente probadas (y razonables) que, sin embargo, parecían
no tener equivalencia en el mundo “incipiente” de las visualizaciones. ¿Cómo era posible…? Sí:
la llamada de lo desconocido hizo mella una vez más… y decidimos intentarlo: nos lanzamos a crear
un modelo de heurística para visualizaciones. Basándonos en la heurística web y en el Diagrama de
Infovis (Dürsteler & Engelheart), identificamos primero las grandes categorías de preguntas que sería
necesario realizar para cubrir los distintos aspectos de una visualización, a saber:
• Objetivos
• Datos
• Codificación visual
• Layout
• Textos
• Interacción
• Accesibilidad
Detectamos unos 60 puntos a comprobar, aunque no todas las preguntas aplican en todas las visualizaciones.
Marcamos en azul las 20 que nos parecían más críticas y rehicimos la formulación de algunas
preguntas para evitar ambigüedades.
Tras algunas vueltas ésta fue, finalmente, nuestra propuesta teórica, que esperamos poder discutir,
corregir y mejorar con la colaboración de compañeros y profesores, hasta dar con un modelo operati-

6. Test de evaluación y usabilidad
Four ways to Slice Obama’s 2013
Budget Proposa, en el New York
Times, 12 Febrero 2012.
Ejemplo de uso de círculos para
codificar cantidades, con una leyenda
de círculos anidados como
referencia. En este caso, el color
también se utiliza en una escala
divergente para codificar el porcentaje
de incremento o descenso
sobre los presupuestos del 2012.
http://www.nytimes.com/
interactive/2012/02/13/us/
politics/2013-budget-proposalgraphic.html
vo para la comunidad de visualizadores: http://goo.gl/hYOxA. El documento es público, pero también
puede consultarse una copia íntegra en el anexo.
Autoevaluación heurística y recorridos cognitivos
Tras algunas pruebas, conseguimos una versión de los prototipos que se acercaba bastante a lo que
teníamos en mente: http://goo.gl/oBjlB
Sobre esa versión aplicamos los test de usabilidad que podíamos realizar internamente: la heurística,
ya presentada, y los recorridos cognitivos, una técnica que consiste en auto-recorrer la visualización
probando distintos circuitos de navegación, poniéndose en la piel de los posibles usuarios definidos en
la creación de Personas y Escenarios e imaginándose qué tipo de dudas o problemas podían suscitarles.
La evaluación fue más positiva de lo esperado: habíamos cubierto, tanto en la concepción como en la
implementación gráfica, buena parte de los preceptos que creemos exige una buena visualización (aunque
sí, es cierto: la heurística la definimos nosotros mismos; había muchas posibilidades de que lo que
teníamos en mente al concebirla y lo que teníamos en mente al concebir la visualización coincidiera).
Aún así, detectamos algunos puntos que generaban dudas o necesitaban mejoras:
• Información contextual. No estábamos ofreciendo ningún tipo de contexto sobre el origen del
problema a visualizar: no había introducción a la temática ni explicación sobre la procedencia de los
datos ni su fecha de extracción. Tampoco ofrecíamos información acerca de la autoría: en ninguna
parte podían localizarse nuestros nombres ni una forma de contacto. Lo cierto es que, tratándose
de un prototipo para una herramienta empresarial construida a medida de las necesidades de la
empresa catalana, no se nos había ocurrido pensar que el contexto fuera necesario – los destinatarios
estaban más que al corriente del contexto de los datos. Nos dimos cuenta que quizá esos puntos
de la heurística tenían más sentido en visualizaciones públicas, para el gran consumo de público.
Aún así, decidimos añadir la autoría, los datos de contacto, y la referencia a los datos que estábamos
teniendo en cuenta en una sección “Acerca de” o similar.
• Normalizaciones. Tras haber oído decenas de advertencias sobre el peligro de codificar cantidades
con círculos, ahí estábamos nosotros, desafiando a los dioses de las comparativas y codificando
ventas con objetos radiales, tan difíciles de comparar. Y ahí estaba la heurística para recordarnos el
riesgo: ¿se habían normalizado los datos para que las cantidades fueran representadas por el área,
y no por el radio de la circunferencia? Sí, se había hecho.
Los círculos se habían generado con el software online gratuito Many Eyes de IBM, y habíamos verificado
varios casos para asegurarnos que, visualmente, un círculo con valor “900” tuviera el triple
de área visual que un círculo con valor “300”. Para que el área sea proporcional al valor hay que
55

6. Test de evaluación y usabilidad
56
tomar la raíz cuadrada (sqrt=Square Root) del valor a graficar dividido por Pi, y usar el resultado
para generar el área del círculo.
• Escalas de referencia. La heurística demanda que, si hay codificaciones métricas, se dé una escala
de referencia. Nosotros habíamos incluido un eje vertical que permitiera encontrar el valor de
las barras métricas (los troncos) que codifican las unidades vendidas (UNF). Sin embargo, con las
áreas de los círculos, que al fin y al cabo también tenían un valor métrico, la escala se nos complicaba.
Llegamos a la conclusión que lo más útil sería ofrecer siempre la cifra total explícita, como
una etiqueta, y añadir una leyenda de referencia rápida con distintos tamaños de círculos, aunque
encontrar la correspondencia exacta entre los círculos generados y la leyenda no sería tarea fácil
para el usuario.
• Interacción. Pronto detectamos que una de las áreas en las que nuestros tenían más deficiencias
era en interacción: nos habíamos preocupado mucho por la coherencia de la codificación estadística
y conceptual, pero los elementos interactivos en parte quedaban escondidos y en parte no habían
sido definidos: los enlaces no parecían enlaces, no quedaba claro dónde podía clicarse y para qué,
no había una referencia clara para el usuario de en qué parte del recorrido estaba… Para ser capaces
de detectar toda la interactividad necesaria, concluimos que lo más operativo sería hacer una
versión realmente interactiva de los prototipos estáticos, para asegurarnos que la navegación y los
recorridos eran posibles.
El resultado de las mejoras derivadas de la heurística puede verse en http://goo.gl/isl3e. Ver el capítulo
8. Visualización final para más detalles.

6. Test de evaluación y usabilidad
Test de usuario
Los test de usuario son un test externo que se realiza con usuarios ajenos al proyecto que cumplen
ciertas condiciones (y se asemejan a nuestro usuario potencial). Se realiza para detectar problemas
cualitativos, y consta de unos cuestionarios básicos y unas pruebas de ejecución de tareas. Mientras el
usuario intenta cumplir las tareas propuestas, nuestro papel es observarlo y tomar nota de su comportamiento,
comentarios y sensaciones.
Lo cierto es que la concepción de la visualización, su prototipado, su programación y su narración se
llevaron por delante el tiempo del proyecto y no pudimos llegar a hacer test de usuario sistematizados
con desconocidos. Pero aún así, estuvimos evaluando las herramientas que nos hubieran permitido
hacerlos, y planteando la estructura del test, con sus tareas y cuestionarios.
Las herramientas online que probamos para ejecutar y monitorizar los resultados de los test fueron:
Para cuestionario
https://es.surveymonkey.com
LostinDarkness / wellfindthelight
Para la evaluación de la visualización
http://www.loop11.com
LostinDarkness / wellfindthelight
Versión gratuita limitada a 5 tareas y 2 preguntas.
Y he aquí los cuestionarios y tareas previstos:
Cuestionario Previo. Datos de perfil (5min)
• ¿Cuántos años de experiencia tienes en navegación por internet?
• ¿Cuántos años de experiencia tienes en el sector óptico?
• ¿Has utilizado previamente un software de Business Intelligence? ¿Qué tal fue la experiencia?
• ¿Qué expectativas tienes con esta visualización? ¿En qué esperas que te ayude?
Cuestionario Pre-tarea (1min)
• Para conseguir esta tarea, ¿cuánto tiempo esperas emplear?
• ¿Crees que será difícil conseguirlo?
Tareas (40min). Think aloud!
Partíamos de la base de que el test debe plantearse con preguntas concretas y guiadas, especificando
claramente cuánto tiempo se permite para realizar la tarea. Para cada tarea había que definir un nombre,
un escenario (instrucciones y contexto), una URL de inicio y una URL de fin; en nuestro caso, sin
embargo la visualización no tenía diferentes URLs… eso generaría algún problema de adaptación con
las herramientas online disponibles para hacer las evaluaciones, pero siempre podríamos utilizar la
observación directa para saber si el usuario había llegado a buen puerto o no.
Estas fueron las tareas propuestas:
1. ¿Qué subfamilias de lentes orgánicas estaban generando los mayores beneficios absolutos en
junio 2008? (3’)
2. Compara las ventas netas de los distintos tipos de lentes según foco en marzo 2008. ¿Qué grupo
de lentes generó mayores márgenes porcentuales de beneficios? (5’)
3. ¿Qué tipo de tratamiento se estaba vendiendo más en diciembre 2008? ¿Sobre qué lentes se aplicaba,
mayoritariamente? (3’)
4. ¿Cómo evolucionaron las ventas de las distintas marcas en el último trimestre de 2008? (3’)
5. ¿Qué provincia generaba mejores márgenes de beneficio para las lentes progresivas orgánicas en
febrero 2008? (2’)
57

6. Test de evaluación y usabilidad
58
El tipo de información que debíamos anotar era:
• el think aloud, todo aquello que comentara el usuario. Luego clasificaríamos los comentarios:
dudas, confusiones, interjecciones, quejas, suposiciones...
• el silence think, o lenguaje corporal, en todas sus manifestaciones:
• expresiones faciales (existe un diccionario: face-and-emotion.com).
• movimientos en la silla (cuando no entendemos algo, nos acercamos al monitor; cuando nos
ponemos nerviosos, nos tiramos para atrás en la silla...).
• movimientos del ratón (si dudamos, movemos el ratón de un lado a otro; si vamos directos a
un enlace, es un movimiento que dibuja una línea recta. Y parece que cuando nos estresamos,
apretamos más fuerte el ratón).
• ¿Se ha logrado la tarea? ¿Con qué efectividad?
• Tiempo empleado (y tiempo estimado)
• Número de clics
• Errores únicos
• Errores repetidos
• Tipo de errores
• Número de veces que llega a la misma página
• Comentarios
Sabíamos de la existencia de software como Morae o Camtasia, que contabilizan los clics, errores, etc.
de manera automática. En nuestro caso, la medida debía ser observada y anotada aproximativamente.
Cuestionario Post-tarea (1min)
• ¿Crees que has conseguido darte de alta/la tarea?
• ¿Te ha parecido fácil o difícil, de 0 a 5? (0: muy fácil; 5: muy difícil).
Encuesta SUS (5min)
El usuario marca su grado de conformidad del 1 al 5 con una lista de afirmaciones. Las afirmaciones
impares son positivas; las pares, negativas. Para calcular el resultado, a las positivas hay que restarle
1 al número marcado. A las negativas, se les resta desde 5 el número marcado por la persona. De esta
manera ambas escalas se convierten internamente a un rango del 0 al 4. Se suman todas las restas y se
multiplica por 2.5 con lo que el máximo valor posible es 100 (2.5x4x10 preguntas). El número resultante
es el porcentaje de satisfacción según la escala SUS.
• Creo que me gustaría usar esta visualización frecuentemente
• La visualización me ha parecido innecesariamente compleja
• Creo que la visualización es fácil de usar
• Creo que necesitaría la ayuda de un técnico para poder usar la visualización
• Creo que las distintas funcionalidades están bien integradas
• Creo que hay mucha inconsistencia en la visualización
• Imagino que la mayoría de gente aprenderá a usar la visualización rápidamente
• Se me ha hecho pesado usar la visualización
• Me he sentido muy cómodo usando la visualización
• Necesito aprender muchas cosas antes de poder utilizar bien esta visualización

7
esculpiendo código
Tiempo de podar el árbol para que crezca sano.

7. Código
60
Antecedentes
Programar árboles es ciencia infusa para mí.
Durante la fase de exploración habíamos realizado transformaciones en los datos, operaciones de limpieza
y filtrado para las acciones de EDA, pero las tareas más complejas estaban por llegar una vez que
abordásemos la programación de nuestra aplicación.
Llegado el momento y durante dos semanas de investigación, tests prueba-error, consultas a los gurús
(gracias Víctor) y algunos logros trasnochados, la tarea fundamental de recuperación y moldeado de los
datos se fue complicando hasta convertirse en un nudo irresoluble que atascaba nuestro mecanismo
visualizador.
Frustradas nuestras expectativas, resolvimos continuar adelante con la definición y desarrollo de la
idea de los árboles que representasen las ventas, dando como resultado tres aproximaciones al modelo
ideal que se iba construyendo en nuestras cabezas.
1. Gráficos interactivos complementarios: Coqueteos con librerías específicas para visualización de
datos, fundamentalmente D3 y Processing, tratando de encontrar nuestra metáfora en las galerías de
ejemplos:
Sunburst
Radial Tree
2. Simulación de la aplicación: Descrita más adelante en el capítulo 5, Definiendo la Interacción.
3. Descripción funcional de las tareas necesarias para programar los árboles:
Funcional
1. Generación de datos estructurados. (ver final capítulo 1. Explorando el Terreno)
2. Recuperación y procesado de los datos. La recuperación de datos la realizamos por medio de funciones
recursivas que recorren los nodos del árbol acumulados en una archivo .json y suman los valores
para cada uno de los niveles padre y establecen su valor de normalización.

7. Código
Normalización de valores: Consistente en detectar el valor más alto de nuestra muestra de datos y
restarle el más bajo. El resultado lo dividimos entre el número de rangos que queremos. El resultado lo
dividimos a su vez por cada uno de los valores resultando la posición para cada uno de ellos.
En las simulación asignamos el valor normalizado de la suma de importes para codificar gráficamente
los siguientes valores:
Suelo (1/3)
Textura: suma de importes para la marca seleccionada
(MARCA A, MARCA C)
Tronco (1/5)
Ancho: suma de importes para el foco seleccionado
(MONOFOCALES, BIFOCALES, PROGRESIVOS)
Ramas (1/3)
Ancho: suma de importes para los materiales seleccionados
(ORGÁNICO, MINERAL, PROGRESIVO)
Hojas (1/5)
Color: suma de importes para los tratamientos seleccionados (COLOR, TRAT-COL, COLOR
H-C,...)
Y el del total de unidades para:
Suelo (1/3)
Altura: suma de unidades vendidas para la marca seleccionada
(MARCA A, MARCA C)
Tronco (1/3)
Altura: suma de unidades vendidas para el foco seleccionado
(MONOFOCALES, BIFOCALES, PROGRESIVOS)
Ramas (1/3)
Altura: suma de unidades vendidas para los materiales seleccionados
(ORGÁNICO, MINERAL, PROGRESIVO)
Hojas (1/3)
Número: suma de unidades vendidas para los tratamientos seleccionados
(COLOR, TRAT-COL, COLOR H-C,...)
61

7. Código
62
Por lo tanto nos queda una estructura visual de posiciones en forma de árbol a la que asignamos valores
a cada posición.
(function(a){
a.fn.extend({
crearArbol: function(suelo,tronco,ramas, hojas){
//Recorre todos los elementos encapsulados
this.each(function(){
// Generamos los elementos que componen el arbol
});
}
});
})(jQuery);
Función javascript que genera el esqueleto y asigna un valor a cada posición.

7. Código
3. Lógica de representación. Generamos unas matrices visuales (técnica sprites css*) que posicionamos
en nuestra estructura de acuerdo a su valor normalizado.
Suelo y tronco.
Ramas
Hojas
63

7. Código
64
El último paso es un juego de ocultación en el que los valores de cada posición actúan de máscara para
las matrices visuales

8
visualización final
Propuesta final y análisis de la estructura
y sintaxis de sus componentes gráficos

8. Visualización Final
66
Análisis de la estructura y sintaxis de los componentes gráficos
Gráfico principal: gráfico de árboles
• Tipo de gráfico: La representación está organizada en un multipanel compuesto de un gráfico híbrido
de tipo estadístico de tiempo y de conéxión (árboles que cambian mes a mes) y un gráfico temporal en
la parte inferior izquierda.
• El espacio métrico del gráfico estadístico de conexión es significativo pero no integral. Mientras el eje
vertical o de ordenadas (Y) es un eje métrico de escala cuantitativa, el eje horizontal o de abcisas agrupa
la información por categorías pero en una escala categórica. El espacio métrico del gráfico temporal se
comporta de similar forma si bien la escala horizontal es secuencial u ordinal.
• Correspondencia gráfica: la correspondencia es de tipo metafórica tanto para el gráfico estadístico
como para el temporal.
• A nivel de los objetos destacar:
Copas de los árboles:
• Rol informacional para mostrar las Ventas Netas o el Margen en valor absoluto.
• Presentan una correspondencia metafórica (proporcionalidad al volumen de ventas o margen)
y también arbitrario-convencional (escala cromática dicotómica para márgenes por encima
o debajo del promedio)
• Respecto al espacio se comportan como localizadores de volumen y también de punto (centro
que marca altura para el tramo inicial o tronco, no así cuando se despliega en los niveles
2º y 3º).
• Se relacionan con otros objetos (copas) a partir de los atributos de tamaño y de llenado de
área (color) así como mediante conexiones con los nodos previos a la copa (nodos padre).
Etiquetas en las copas:
• Componentes con rol informativo. Son objetos gráficos no pictóricos (textuales) contenidos
espacialmente dentro de las copas.
Conectores entre copas:
• Rol informacional. Líneas que enlazan (objeto-objeto) nodos y copas o nodos con nodos. No
son dirigidos (aunque se podrían convertir en dirigidos para jerarquizar la relación sugerida

8. Visualización Final
en la verticalidad). Su tamaño tiene significado métrico y es proporcional al valor de UNF
para esa subfamilia.
Ejes verticales:
• Gráfico estadístico (árboles): Eje métrico de referencia de escala lineal que marca la cantidad
de UNF según la altura de las copas (sólo para el primer nivel de desglose cuyo tronco
crece en vertical de forma paralela al eje).
• Gráfico temporal: Eje métrico de referencia de escala lineal que marca la cantidad de Ventas
netas o Margen para cada mes.
Ejes horizontales:
• Gráfico estadístico (árboles): Eje métrico de escala categórica (familias)
• Gráfico temporal; Eje no métrico, ordinal con los meses secuenciados.
Leyendas: (ver ‘Gráfico secundario’)
Gráfico secundario: mapa con burbujas
• Tipo de gráfico: multipanel compuesto de un mapa con información estadística y cronológica
(burbujas) y un gráfico temporal en la parte inferior izquierda.
• El espacio métrico del mapa es integral y representa una distribución física sobre una superfície
geográfica. Gráfico temporal de la parte inferior: ya se ha analizado previamente.
• Correspondencia gráfica: Mapa (literal) y burbujas (metafórica basada en el tamaño)
• A nivel de los objetos destacar :
Leyendas:
• Objetos compuestos en un espacio no estructurado (no importa el orden en que aparezcan
los diferentes objetos incluidos) realizando un rol de componentes informativos con
una relación de agrupación espacial de los objetos simples que las componen.
Burbujas (de manera similar a las copas pero sin información cromática):
• Rol informacional para mostrar las Ventas Netas o el Margen en valor absoluto.
• Presentan una correspondencia metafórica (proporcionalidad al volumen de ventas o
margen) Respecto al espacio se comportan como localizadores de volumen y localizadores
de punto geográfico (centro)
• Se relacionan con otros objetos (copas) a partir de los atributos de tamaño.
67

8. Visualización Final
68
Gráfico secundario: mapa de provincias x colores
• Tipo de gráfico: multipanel compuesto de un mapa con información estadística y de tiempo (burbujas)
y un gráfico temporal en la parte inferior izquierda.
.
• El espacio métrico del mapa es integral y representa una distribución física sobre una superfície
geográfica.
• Correspondencia gráfica: Mapa (literal) y áreas coloreadas (arbitrario-convencional)
• A nivel de los objetos destacar:
Provincias:
• Delimitadas por localizadores de superficie con rol referencial.
• La relación entre los objetos geográficos a nivel de atributos se establece en función del
llenado de área mediante diferentes colores en una escala secuencial.
Burbujas (de manera similar a las copas pero sin información cromática):
• Rol informacional para mostrar las Ventas Netas o el Margen en valor absoluto.
• Presentan una correspondencia metafórica (proporcionalidad al volumen de ventas o margen)
• Respecto al espacio se comportan como localizadores de volumen y localizadores de punto
geográfico (punto central de la provincia=punto central de la burbuja)
• Se relacionan con otros objetos (copas) a partir de los atributos de tamaño.
Icono (“back to” árbol)
• Proponemos aquí establecer una nueva clasificación para los elementos gráficos de una
representación que permiten cambiar interactivamente las condiciones de la visualización:
• Objeto: en este caso elemental
• Rol: Interactivo
• Correspondencia: en este caso metafórica
• Modo de expresión: pictórico esquemático
• Relación objeto-espacio: localizador de interacción
• Relación espacial objeto->objeto(s): Modificador

8. Visualización Final
Análisis de negocio en base a la visualización final
Gráfico principal: gráfico de árboles
Las lentes monofocales son las más vendidas tanto en volumen de transacciones como en valor y lo
hacen al margen promedio de venta de lentes.
• Si desplegamos el árbol de lentes monofocales vemos que ese margen porcentual es el
resultado de un mix dispar entre lentes minerales con un margen% claramente superior al
de las orgánicas aunque con menos de 3x el valor de ventas que éstas.
Las lentes progresivas aportan un % de margen superior a las monofocales y un valor de venta por
unidad (UNF) también superior (tal como se refleja en el tamaño de la copa en relación a su altura).
69

8. Visualización Final
70
• Al desplegar la información por materiales vemos un efecto contrario al de las monofocales:
aquí las lentes orgánicas progresivas tienen un % de margen superior a las minerales si
bien las ventas netas (VN) de las orgánicas sigue siendo muy superiores (casi 10x) a las VN
de las lentes progresivas minerales.
En conjunto las lentes bifocales son las que menos volumen y valor aportan a la empresa catalana
siendo además su margen porcentutal inferior al promedio de la empresa.
• Analizando los datos de las lentes bifocales según los materiales de que están hechas lo
único que llama la atención es que la subfamilia más vendida es la mineral y no la orgánica
como pasaba en las otros dos lentes. Esto quizás puede ser debido a una cuestión histórica
relacionada con el tipo de cliente de mayor edad al que va dirigido este producto y que puede
preferir el soporte mineral.
Al introducir las marcas en el último nivel podemos detectar que las subfamilias con mayores ventas
netas son las Orgánicas de Marca A (tanto monofocales como progresivas) mientras que el mejor % de
margen se consigue con la ventas de las lentes Progresivas-Orgánicas de la Marca A.
El nicho ‘promesa’, a nivel de potencial de ventas y margen alto sobre unidades vendidas, es precisamente
el de las transacciones de lentes de ese tipo: Progresivas-Orgánicas-Marca A mientras que el
segmento que aparece como ‘maduro’ (muchas ventas en udes., valor alto, margen bajo) correspondería
a las lentes Monofocales-Orgánicas-Marca A.
Gráfico principal: gráfico temporal
Por otro lado a evolución temporal de las ventas muestra una tendencia a la baja para todas las categorías
(y por tanto para el conjunto de las ventas) desde principio hasta final de año con repuntes en
abril y julio.
Gráfico secundario: mapa por provincias (burbujas)
Si profundizamos en el análisis de las ventas de Progresivos_Orgánicos_MarcaA y desglosamos los
datos por provincias, podemos ver:

8. Visualización Final
La 1ª división de las ventas netas por provincias se concentra en 3 áreas: Barcelona, Madrid y Valencia.
Hay una segunda división que incluye a Vizcaya, Málaga, Sevilla, Alicante y también a Murcia.
Gráfico secundario: mapa por provincias (escala cromática)
Si solicitamos los datos per cápita podemos ver cómo existe un ranking diferente al anterior debido a
esa normalización poblacional de datos.
En ese ránking Valencia es la provincia con más ventas x cápita y la siguen, con unas ventas x cápita
superiores al promedio, provincias como Palencia, Murcia, Lleida, Rioja o Vizcaya mientras que otras
muestran un potencial por desarrollar en cuanto a ventas x población residente (provincias de Castilla
La Mancha, Extremadura, Aragón, Asturias o Cantabria)
71

8. Visualización Final
72
Si finalmente pasamos a la vista que mide el % de ventas de esa referencia sobre el total de las ventas
de lentes en cada provincia podemos identificar aquellos lugares donde esas SKUs están por debajo (o
por encima) del mix habitual.
Así, y siendo las lentes progresivas orgánicas una familia de lentes con un margen superior, nos puede
interesar potenciar áreas donde aparecen infradesarrolladas como Huesca, León, Burgos o en general
la zona central de España. En contraste nos puede ser útil estudiar (benchmark) las causas que han
llevado a que provincias como Lleida, Lugo especialmente Palencia y Valencia tengan una presencia
tan alta en el mix de este tipo de productos de elevado margen.

anexos
documentos que, de no estar aquí,
hubieran hecho de esta memoria una
lectura eterna...
(... y un bonus track)

Anexos
74
Treeninsights: Imágenes y comentarios
Estructura de la BBDD creada con MySQL.
En el diagrama Entidad-Relación (ER) adjunto se muestra la estructura de la BBDD creada con MySQL.
En ella se utiliza a las Familias como llave principal para acceder a la tabla de información de las variables
de tipo de producto, según el cuadro de equivalencias enviado por la empresa catalana. Igualmente se crean
tablas en las que se etiquetan con nombres más descriptivos tanto las geografías (p.ej. ES_08=Barcelona)
como las fechas, servicios…
Cuartiles para establecer valores atípicos
Uso de R para obtener cuartiles de la BBDD.
% de valores atípicos de VEA por Niveles
Detección de patrones de valores atípicos en función del tipo de producto.

Anexos
% de valores atípicos de VEA x capas
Los productos en los que se aplica la capa Color-AR+ presentan un porcentaje alto de transacciones de
margen atípicamente elevado.
Si analizamos sólo a nivel de tratamientos aplicados a las lentes vemos como un porcentaje muy elevado de
las transacciones comerciales que incluyen la capa de Color-AR+ tienen un margen final atípicamente alto
en relación al promedio de transacciones totales.
También es el caso de Transitions, AR+ o Foto-AR si bien el primero de estos tres tiene también valores altos
de transacciones atípicas negativas, seguramente debidos a devoluciones. Una hipótesis posible, a falta de
otros datos, es que esta lente en concreto, que cambia de color según la intensidad de luz externa, tenga más
problemas de adaptación que otras y acabe produciendo devoluciones de consumidor, lo cual es una oportunidad
para el desarrollo de un producto mejor o de una formación adecuada al cliente final que adecúe las
expectativas a la realidad del producto.
% de valores atípicos de VEA x red de ventas
El comportamiento entre las diferentes redes de ventas es dispar en cuanto al mix de transacciones de margen
atípico alto o bajo
Un mismo análisis por redes de ventas permite detectar redes que tienen porcentajes de transacciones comerciales
con valores atípicos positivos altos (caso de MAL_3ML o BAR_3BR, NOV_ZZZ, BIL_3BL…), que en
ocasiones se compensan en parte por valores negativos de devoluciones (BAR_3BR) y en otras extrañamente,
sólo presentan valores positivos altos (CEN_LI1, KAS_1KC) sin ninguna devolución o transacción atípicamente
baja.
75

Anexos
76
PERSONAS Y ESCENARIOS
La técnica de personas y escenarios es empleada en Diseño de producto y Usabilidad para ayudar a
crear productos que realmente se ajusten a las necesidades y condiciones de sus usuarios potenciales.
Básicamente, consiste en la definición de unos usuarios ficticios o “Personas” (del latín persona,
máscara o personaje), que nos servirán como modelo de referencia para diseñar, en éste caso, nuestra
visualización. La idea es dejar de utilizar el término genérico “usuario” en la conceptualización, y empezar
a diseñar pensando en una persona concreta, con sus necesidades y sus objetivos.
La teoría guió nuestros pasos en la creación de estos perfiles ficticios:
Pregunta a los que saben: entrevistas
Antes de hacer el diseño de producto, nuestro primer paso debía ser entrevistar a los skateholders: es
decir, a todas las personas que iban a tener algo que ver con la visualización. Empresarios, dueños del
producto, diseñadores, usuario final, familiares del usuario final... se trataba de rastrear todo el entorno
para detectar posibles circunstancias de uso.
En nuestro caso, no fue posible una exploración directa del entorno empresarial donde iba a utilizarse la
visualización en la que trabajábamos, pero sí que teníamos acceso a personas que trabajaban en él y poseían,
por tanto, información de primera mano: el Director de Innovación y la Responsable de Business
Intelligence. A través de ellos obtuvimos la información relativa a los distintos perfiles potencialmente
interesantes para nuestro proyecto, a saber:
1. Director financiero
2. Director de Marketing
3. Director de Ventas España
4. Responsable de Business Intelligence
Basándonos en trabajos previos provenientes del Diseño de Producto, preparamos un modelo de entrevista
muy focalizado en la detección de problemas en el trabajo diario del usuario. Sin embargo, cuando
pusimos en práctica el cuestionario nos dimos cuenta que había varias preguntas no pertinentes, y
otras cuyas respuestas se repetían sistemáticamente, sin variaciones apenas de un usuario a otro; en la
segunda tanda de entrevistas ajustamos las preguntas. No siempre obtuvimos respuesta en todos los
puntos, pero aún así ofrecemos aquí el modelo depurado de cuestionario, como futura referencia para
próximas aplicaciones. Hay que tener en cuenta, sin embargo, que es un modelo muy enfocado al uso de
visualizaciones en un contexto empresarial.
Perfil
1. Nombre
2. Cargo
Tarea
3. Responsabilidades clave
4. ¿Qué entregables visuales / informativos produce y para quién? ¿Con qué herramientas?
5. ¿Cómo se mide el éxito de sus entregables?
6. ¿Qué problemas tiene en la generación de entregables, y cómo le gustaría resolverlos?
Formación
7. ¿Qué tipo de estudios ha realizado?
8. ¿Qué experiencia tiene con herramientas de Business Intelligence?
9. ¿Qué experiencia tiene con visualizaciones?
Escenario
10. ¿Cuándo va a hacer uso de la visualización y durante cuánto tiempo?
11. ¿En qué entorno físico?
12. ¿Los ordenadores desde los que trabaja tienen acceso a la BBDD que nutre la visualización?
Comentarios adicionales

Anexos
Creación de personajes y escenarios
Efectuadas las entrevistas, el siguiente paso era crear los personajes. La consigna estaba clara: no
podíamos caer en la tentación de perfilarlos con datos demográficos, buscando una muestra equitativa
y genérica… el ejercicio pretendía todo lo contrario: tenían que ser casos reales. En nuestro caso, eso
significaba que todos los usuarios eran profesionales (no había usuarios con motivaciones ociosas),
regulares (no había usuarios casuales), etc.
Para cada personaje había que definir, asimismo, unos escenarios de uso. ¿Dónde usarían nuestra
visualización? ¿Cuándo? Y sobre todo, ¿para conseguir qué? En nuestro caso, tratándose de una visualización
pensada como herramienta empresarial, los escenarios físicos de uso resultaron ser muy
parecidos: una oficina donde se trabaja individualmente rodeado de gente. Sin embargo, los fines de los
distintos usuarios variaban.
Estos fueron los perfiles que obtuvimos.
1. Director Financiero: ¿Cuánto hemos ingresado este mes?
Se encarga de gestionar todas las finanzas de la compañía, de controlar el flujo de caja. Lo suyo son las
grandes cifras, la gran masa monetaria, que controla diaria, semanal, trimestral y anualmente.
Sólo utiliza la información de ventas indirectamente: no le importa el detalle por provincia, ni por red
de venta, ni por producto: sólo cuánto ha entrado ese mes (y cuánto tiene que pagar, y si los números
cuadran).
Está interesado en el comportamiento estacional de las ventas. Para él, es determinante cuándo se
vende y cuándo se cobra: debe tener en cuenta ese gap temporal para prever la cobertura de pagos con
fuentes alternativas (créditos).
Elabora informes que entrega al director general y ejecutivo. Tiene una experiencia media tratando con
herramientas de Business Intelligence, y genera sus informes con herramientas de ofimática.
Consulta los datos a diario, pero necesita información de otro dataset, además del nuestro.
77

Anexos
78
2. Director de Marketing: ¿Qué tal se están vendiendo las progresivas?
El Dr. de Marketing es el responsable de la estrategia de llegada a mercado. Se encarga de toda la campaña:
define el producto, su precio, su comunicación, sus canales de comercialización… y es el responsable
de evaluar el éxito de la campaña.
Existe un Product Manager para las grandes categorías de foco de lentes: progresivas, monofocales y
bifocales. El PM de progresivas, por lo tanto, es responsable de todas las lentes progresivas, sean del
material que sean, del índice de refracción que sea y el modelo que sea. La categoría madre es el tipo de
foco; las marcas no son relevantes para las consultas: son agrupaciones genéricas.
Está interesado en obtener información del comportamiento de un producto (progresivas), y acceder a
los detalles de ese conjunto (comportamiento según índice de refracción, según material, según tratamiento).
Elabora informes que entrega al Director Comercial (integrado en el Comité de Dirección).
3. Director de Ventas España: ¿Quién vende qué? ¿A quién? ¿Por cuánto?
El director de Ventas tiene a su cargo a los Área Managers, que a la vez tienen a su cargo a todos los vendedores.
Actualmente recibe informes generados por el departamento de Business Intelligence, pero
no trabaja directamente con la herramienta. Si pudiera hacerlo, sería una mejora. No tiene demasiada
experiencia con herramientas de Business Intelligence ni con visualizaciones.
Los informes contienen indicadores estándares sobre:
- Qué se vende cada mes por vendedor (+ acumulado, + evolución)
- Qué se vende cada mes por producto (+ acumulado, + evolución)
- Qué se vende cada mes por cliente (+ acumulado, + evolución)
Si hay campañas en marcha o problemas con un producto, se generan informes específicos. Los informes
(basados en tablas) se utilizan en reuniones para demostrar evoluciones. Están interesados en
tener noticia inmediata cuando algún cliente cae o sube considerablemente (informes de alarmas top
up/top down).
4. Responsable de Business Intelligence: libertad para analizar
Son los encargados de explotar al máximo los datos para obtener insights que nos indiquen futuras estrategias
de acción: son la analítica del negocio. Responden a las peticiones específicas de información
de todos los departamentos.
Elaboran informes mensuales para:
• Marketing: cuánto se ha vendido de cada producto, especialmente si ha alguna campaña en marcha.
Se evalúan los resultados que está dando el producto vs los objetivos marcados. Los indicadores
de estos informes son bastante variables (se requieren datos externos a nuestro dataset).
• Dr. General / Dr. Financiero: Las ventas propias vs el estado del mercado. Se trata de evaluar si
estamos enfocados con las demandas que genera el mercado, y de cuál es nuestra posición respecto
a los competidores (se requieren datos externos a nuestro dataset).
Los informes generados se construyen a partir de consultas a la base de datos, con peticiones de dimensiones
cruzadas concretas, que generan una tabla dinámica. Los gráficos que se incluyen son tablas,
en su inmensa mayoría. La generación de estos informes les exige una dedicación temporal importante,
limitando las posibilidades de que se dediquen a hacer Business Intelligence, que debería ser el foco de
su cometido. Idealmente, los departamentos deberían poder atacar directamente a la base de datos y
generar visualizaciones.
Su conocimiento de herramientas de Business Intelligence es alto, pero están poco acostumbrados a
trabajar con visualizaciones. Dedica la jornada íntegra de trabajo a lidiar con los datos, e una oficina de
trabajo diáfana, rodeado de mucha gente.

Anexos
Anexos online
La siguiente documentación, que se presenta como anexa al proyecto, puede encontrarse y consultarse
de manera más satisfactoria en la siguiente carpeta compartida en Dropbox:
https://www.dropbox.com/sh/7jmvsr474f8f8gb/wq_8vtqA1Z/Anexos
Modelo de Heurística
http://bit.ly/L7sChu
El modelo de evaluación heurística para visualizaciones que proponemos con este proyecto puede encontrase,
en Excel, en esta dirección. Obsérvese que se ha respetado el modelo de documento de la
heurística web original, que prevé un formulario para cada evaluador, y unas columnas en las que se
consigna la frecuencia de aparición del error, si es que existe, y su grado de impacto, que se determina
en función de hasta qué punto bloquea la navegación del usuario.
Prototipos
https://www.dropbox.com/sh/7jmvsr474f8f8gb/b0V1l5aPJT/Anexos/Prototipos
El proceso de imaginar una interfaz donde mostrar nuestra visualización fue largo, costoso e iterativo.
Trazamos variedad de opciones sobre una misma idea base. En esta carpeta pueden consultarse 4 de
las versiones de prototipos que preparamos, desde el sketch más inicial (en PowerPoint) a distintas versiones
en Axure. Las versiones en Axure pueden ejecutarse en un navegador y simular la interactividad
que tienen definida (no todos los botones son clicables, pero algunos sí lo son, y tienen una estructura de
páginas navegables). Para ejecutarlos, leer el archivo “Leedme”, incluido en la carpeta.
Presentaciones
https://www.dropbox.com/sh/7jmvsr474f8f8gb/4UPPU0gBOP/Anexos/Presentaciones
Durante los dos meses que duró el proyecto, se prepararon 3 presentaciones parciales en las que dar
cuenta de la evolución, avances y problemas que fueron surgiendo. En este anexo pueden consultarse
los documentos PowerPoint que sirvieron de apoyo visual a esas presentaciones.
Formato maquetación
https://www.dropbox.com/sh/7jmvsr474f8f8gb/wq_8vtqA1Z/Anexos
Adjuntamos la plantilla inicial que se preparó para albergar el cuerpo de esta documentación en In-
Design. En ella se delimitan las cajas reservadas para texto, el encaje que tendrán las imágenes entre
ellas, la localización de los títulos y pies de foto y la tipografía. Puede consultarse más información
sobre el proceso de maquetación en la Presentación3_docu.ppt.
Herramientas (software)
https://www.dropbox.com/s/6rkyaf6wd3gehjx/Project_Tools.png
Mindmap de las 20 herramientas utilizadas en el desarrollo del proyecto, tanto para la visualización,
como para la gestión, el diseño, la programación...
79

Anexos
80
Documentación
Inicialmente se propuso una grilla de 6 columnas para la disposición de los elementos. A medidad que el
proyecto avanzaba, se debió modificar la cantidad de columnas.
En la doble página superior, se observa la grilla de 10 columnas desarrollada para disponer los elementos,
en relacion además a las secciones que se iban sumando a medida que el proyecto iba tomando
cuerpo. Se dispuso un color por sección que serviría para indicar en que capítulo se está.

Anexos
La tipografía escogida es la familia DINPro, neutra, facil de leer en cuerpo de texto y con suficientes
variantes para desarrollar los niveles de contenidos.
81

Anexos
82
Wordle: metagráfico de la
documentación
Visualización de las palabras más
frecuentes aparecidas en este
documento.
La base está formada por la petición
académica inicial, en la que
se describía cómo debía ser el documento.
El tronco central representa
todo el proyecto, y las copas
representan cada uno de los
capítulos de esta documentación.
La visualización se ha realizado
con Wordle, corrigiendo plurales
en los casos más flagrantes,
y militando a un máximo de 100
términos por nube. Los colores,
asignados por Wordle, siguen una
escala de intensidad de paleta
desconocida.

Anexos
83

Anexos
84
Judith Argila
www.mmmmola.com
magnoliasblancas@gmail.com
Hermes Carretero
hermesite.net/receta.html
hermesite@gmail.com
Gilbert Matínez
www.linkedin.com/in/gilbertmg
gilbebo@gmail.com
Ricardo Vega
www.ricardov.cl
rvegamora@gmail.com

Postgrado Visualización de la Información
IDEC - Universitat Pompeu Fabra
2011 - 2012