Cómo diseño una taxonomía de producto desde cero: mi proceso paso a paso

La taxonomía no se improvisa. Antes de crear categorías, hay que entender qué vende la empresa, cómo nombra sus productos, cómo los busca el usuario y qué estructura va a poder sostener el equipo en el día a día. Recorramos mi proceso completo: desde el relevamiento inicial hasta la validación con quienes van a usar esa taxonomía todos los días.

Hay problemas de catálogo que no hacen ruido al principio, pero tarde o temprano aparecen en todos lados. No suelen empezar con un error evidente ni con una ficha rota. Empiezan de forma más silenciosa: dos equipos llamando distinto al mismo producto, categorías que crecen sin criterio, filtros que no ayudan, atributos que compensan decisiones mal resueltas en la estructura, usuarios que no encuentran lo que existe y equipos que sienten que cada alta nueva desordena un poco más el sistema.

En esos casos, el problema de fondo casi nunca es tecnológico. Es conceptual. Y muchas veces tiene nombre propio: una taxonomía mal pensada.

La taxonomía de producto no es solo un árbol de categorías. Es la estructura que define cómo se organiza el catálogo, cómo se lo navega, cómo se lo filtra, cómo se lo entiende internamente y cómo se lo publica después en cada canal. Cuando esa base está mal diseñada, el catálogo no escala: se vuelve más difícil de mantener, más ambiguo y más costoso de usar. Cuando está bien resuelta, en cambio, ordena mucho más que la navegación: ordena criterios, decisiones y trabajo operativo.

Una taxonomía no sirve solo para “ordenar productos”. Sirve para que el catálogo pueda crecer sin multiplicar el caos.

El primer paso no es dibujar categorías: es relevar el problema real

Yo no empiezo una taxonomía abriendo un Excel y armando niveles. Empiezo bastante antes. Empiezo tratando de entender qué está pasando con el dato y con la forma en que la empresa representa sus productos.

Necesito ver de dónde sale la información, cómo llega hoy, qué sistemas intervienen, quién la toca, qué equipos la usan y en qué puntos empiezan las inconsistencias. En esa etapa miro exportaciones de ERP, estructuras del eCommerce, planillas de proveedores, feeds, árboles de navegación existentes, nombres de archivos, fichas comerciales y todo lo que me permita detectar cómo se está pensando hoy el catálogo, aunque sea de forma desordenada.

Lo que busco no es solo volumen ni completitud. Busco patrones. Quiero identificar si una misma familia aparece repartida en lugares distintos, si se mezclan criterios técnicos con criterios comerciales, si hay categorías creadas para resolver excepciones, si la lógica responde a cómo compra la empresa pero no a cómo busca el usuario, o si se intentó arreglar con atributos algo que en realidad pedía una mejor clasificación.

En esta etapa también necesito responder preguntas muy concretas. Qué vende realmente la empresa. Cómo nombra esas cosas. Cómo las busca el cliente. Qué necesita encontrar primero el equipo comercial. Qué exige cada canal. Dónde aparecen los duplicados. Qué tensiones existen entre la lógica del negocio y la lógica de la navegación. Si eso no está claro desde el principio, cualquier taxonomía puede quedar prolija en una presentación, pero inestable en la operación.

Antes de modelar, separo lo que suele venir mezclado

Hay una confusión que aparece muchísimo en proyectos de catalogación: mezclar categoría, atributo y faceta como si fueran la misma cosa. Y no lo son.

La categoría responde a qué es el producto. El atributo describe cómo es. La faceta permite filtrarlo o refinarlo. Cuando esas tres capas se mezclan, la estructura deja de ser útil y empieza a cargar funciones que no le corresponden.

Si tomo como ejemplo una silla de oficina ergonómica negra, la categoría debería responder que es una silla de oficina. El color, el material, las dimensiones o el tipo de respaldo son atributos. Y color, material, precio o marca pueden transformarse después en facetas de navegación. El problema aparece cuando el árbol intenta absorber todo eso y termina teniendo categorías como “sillas negras”, “sillas grandes”, “sillas premium” o “sillas livianas”. Ahí la estructura deja de clasificar tipos de producto y empieza a mezclar criterios de naturaleza distinta.

Ese error parece menor, pero no lo es. Porque cuando el árbol absorbe decisiones que deberían resolverse con atributos o filtros, el catálogo se vuelve más rígido, menos escalable y mucho más difícil de sostener en el tiempo.

Si la categoría responde qué es, el atributo responde cómo es y la faceta responde cómo se filtra. Cuando esas capas se mezclan, el catálogo se desordena aunque parezca completo.

La lógica del árbol tiene que definirse antes del detalle

Una vez que entendí el catálogo actual y separé esas capas conceptuales, recién ahí empiezo a pensar la estructura. Pero tampoco arranco por el nivel más específico. Primero necesito definir cuál va a ser la lógica principal del árbol.

Eso significa decidir con qué criterio se va a organizar el catálogo. Según el tipo de negocio, esa lógica puede estar centrada en el tipo de producto, en la función, en el uso, en la industria, en el segmento o en una combinación controlada de esas dimensiones. Lo importante no es que exista una única fórmula universal. Lo importante es que haya una lógica dominante y que esa lógica sea consistente.

Cuando cada nivel del árbol responde a una idea distinta, el resultado suele ser confuso. Un primer nivel por tipo de producto, un segundo por ocasión de uso y un tercero por material, por ejemplo, genera una estructura difícil de leer, difícil de mantener y poco intuitiva para quien la navega. La taxonomía no tiene que replicar sin filtro la organización interna de la empresa. Tiene que resolver un problema de orden, recuperación y gestión del dato.

A veces el negocio compra de una manera, almacena de otra y vende de otra. Eso es normal. El trabajo de diseño está justamente en decidir qué lógica necesita el catálogo como sistema vivo, no en copiar estructuras heredadas solo porque ya existen.

Cómo bajo esa lógica a una estructura concreta

Cuando la lógica madre del árbol ya está definida, empiezo a trabajar los niveles de forma descendente: de lo general a lo específico. Y en cada apertura me hago la misma pregunta: ¿este nivel agrega claridad o agrega ruido?

No toda profundidad mejora una taxonomía. Muchas veces la complica. Una categoría útil no es la que abre más ramas, sino la que representa un conjunto reconocible de productos, sostiene atributos coherentes, tiene sentido para quien la usa y permite crecimiento sin romper la lógica del árbol.

Si una categoría existe solamente para alojar tres excepciones, para resolver una rareza puntual o para compensar datos incompletos, probablemente no deba existir como categoría. Tal vez necesite otro tratamiento: un atributo, una etiqueta operativa, una regla de publicación o incluso una decisión editorial de navegación. Pero no necesariamente un nodo permanente.

En esta etapa también evalúo si conviene tomar como referencia alguna estructura estándar o una taxonomía externa ya aceptada por el sector o por determinados canales. No para copiarla ciegamente, sino para evitar reinventar clasificaciones que después igual van a tener que mapearse a otros entornos.

La taxonomía no se cierra sola: se valida con quienes la van a usar

Hay algo que para mí es central: una taxonomía no se termina cuando el árbol “cierra” en papel. Se termina cuando fue discutida con quienes van a convivir con esa estructura todos los días.

Por eso, una vez que tengo una primera propuesta, la valido con los equipos que van a cargar productos, enriquecerlos, revisarlos, publicarlos, venderlos o integrarlos con otros sistemas. No busco una aprobación superficial. Busco fricción. Quiero ver dónde aparecen las dudas, las dobles lecturas, los términos ambiguos, las categorías que operativamente no sirven o los casos que hacen tambalear la lógica general.

Ese momento es clave porque muchas taxonomías no fracasan por estar mal pensadas desde lo conceptual, sino por no haber sido contrastadas con la realidad del trabajo diario. Una estructura puede verse impecable en una reunión y resultar inviable en cuanto entra en contacto con la operación.

También es en esta validación donde se ve si el lenguaje elegido tiene sentido compartido. Porque una palabra que para un equipo parece obvia puede significar otra cosa para otro. Y esa ambigüedad, si no se corrige a tiempo, después se multiplica en atributos, categorías, filtros y decisiones de carga.

Una taxonomía no fracasa solo por estar mal diseñada. También fracasa cuando nadie puede sostenerla en el uso cotidiano.

Qué reviso antes de considerarla lista

Antes de dar por cerrada una taxonomía, hago una revisión final con una idea bastante concreta en mente: no busco perfección, busco estabilidad. Necesito saber si esa estructura va a seguir teniendo sentido cuando el catálogo crezca, cuando entren más productos, cuando aparezcan más equipos o cuando se sumen nuevos canales.

Ahí reviso si cada categoría tiene una razón clara de existir, si las aperturas heredan bien la lógica del nivel anterior, si el árbol evita duplicaciones innecesarias, si los atributos acompañan la clasificación, si la navegación probable del usuario está contemplada y si la estructura puede mapearse sin parches a otros sistemas o canales.

Pero además reviso algo todavía más importante: si existe un criterio documentado para futuras altas. Porque diseñar la taxonomía inicial resuelve solo una parte del problema. La otra parte es definir cómo se mantiene. Si no hay reglas de crecimiento, muy rápido aparecen nuevas categorías creadas por urgencia, excepciones convertidas en regla y duplicaciones que vuelven a ensuciar todo lo que se había ordenado.

Los errores que más encuentro en proyectos reales

Después de trabajar en distintos catálogos, hay errores que se repiten mucho. Uno de los más frecuentes es crear categorías para compensar datos pobres. Como faltan atributos o faltan criterios de carga, el árbol empieza a absorber información que no debería vivir ahí.

Otro error muy común es usar lenguaje demasiado interno. Términos que tienen sentido para compras, ingeniería o administración, pero no para quien navega el catálogo ni para quien tiene que enriquecerlo con consistencia.

También aparece mucho la duplicación de conceptos en ramas distintas, sin una política clara que la justifique. A veces eso parece resolver visibilidad, pero después complica breadcrumbs, integraciones, reporting y mantenimiento. Y otro problema clásico es pensar la taxonomía solo para el canal actual. Una estructura que parece suficiente para una web puntual puede romperse en cuanto entra un marketplace, un nuevo país, una expansión de surtido o una implementación PIM más exigente.

Y hay uno más, que parece menor pero no lo es: no documentar el criterio. Cuando la lógica queda solo en la cabeza de quien diseñó el árbol, el proyecto queda atado a una memoria informal. Y tarde o temprano eso se paga.

Diseñar bien una taxonomía es decidir cómo va a crecer el catálogo

Para mí, una buena taxonomía no es la más compleja ni la más sofisticada. Es la que logra ordenar el catálogo con una lógica que el negocio entiende, el usuario puede recorrer y el equipo puede sostener.

Si tengo que elegir, siempre prefiero una estructura clara, defendible y mantenible antes que una arquitectura hiperelaborada que impresiona en una demo pero después nadie puede operar con consistencia. Porque el verdadero valor de una taxonomía no está en cómo se ve, sino en cómo resiste el crecimiento, la excepción, el cambio de canal y el paso del tiempo.

Diseñar una taxonomía desde cero no es un ejercicio decorativo. Es trabajo de base. De ese que no siempre se nota al principio, pero define si el catálogo va a poder escalar con orden o si cada nuevo producto va a agregar una capa más de desorden.

Antes de hablar de automatización, enriquecimiento o escalabilidad, hay que decidir cómo se va a organizar el mundo que ese catálogo intenta representar. Y esa decisión no se improvisa: se releva, se discute, se prueba, se corrige y se documenta. Paso a paso.