Cómo se organiza el catálogo de trámites de un municipio para que alguien los encuentre
Cuando alguien necesita una constancia de residencia para su hijo, no sabe —ni tiene por qué saber— que ese papel lo emite la Secretaría General Municipal. Sabe que necesita el papel. Sabe, como mucho, que tiene algo que ver con “trámites del municipio”.
Ese hueco entre cómo está organizado un ayuntamiento por dentro y cómo busca la gente por fuera es todo el problema de diseñar un índice de trámites. Y es un problema de arquitectura de información antes que de código.
He trabajado en el catálogo de trámites y servicios de un ayuntamiento: más de cien registros, repartidos en varios organismos y decenas de direcciones. Este artículo es lo que aprendí ordenándolos.
El punto de partida era un Excel
Conviene empezar por ahí, porque cambia la naturaleza del trabajo.
Lo que existía no tenía categorías, ni palabras clave, ni nada. Era una hoja de cálculo con enlaces a PDF e información muy básica. Publicada tal cual, eso da una página que cumple con el trámite de “estar publicado” y no sirve para nada más.
Y no servía por una razón concreta: el ciudadano no conoce los nombres técnicos de los trámites. Nadie busca “constancia de residencia con fines de inscripción escolar”. La gente busca palabras sencillas, no burocráticas.
Tampoco le importa el nombre completo de la dependencia —nombres que además cambian cada cierto tiempo—, ni quiere entrar y encontrarse una tabla con cientos de archivos y denominaciones técnicas. Lo que sí funciona es entrar y ver categorías, un buscador y filtros.
Esa fue la propuesta que hice al desarrollar esta sección del portal: no publicar el catálogo, sino convertirlo en algo navegable. Todo lo que sigue son las decisiones que salieron de ahí.
Las dos taxonomías que siempre chocan
Cuando pides el catálogo, lo que te entregan es una hoja de cálculo organizada por organigrama: cada dependencia manda sus trámites, con su clave interna y el nombre de la dirección responsable.
Es un orden real y es un orden útil — para el ayuntamiento. Sirve para saber quién responde de qué, quién actualiza los requisitos y a quién reclamas cuando algo está mal. No es un capricho burocrático: es el mapa de responsabilidades.
El problema es que no es un mapa de necesidades. A la persona que entra a la web no le sirve saber que su trámite pertenece a la “Dirección de Gestión Integral de Riesgos, Protección Civil y Bomberos”. Le sirve saber que ahí resuelve lo del dictamen que le pidieron para abrir su local.
Así que acabas con dos estructuras sobre los mismos objetos:
- La administrativa — organismo → dirección → clave. La que existe de origen.
- La temática — Salud, Agua, Familia, Empleo, Construcción, Ecología… La que hay que construir.
El error clásico es elegir una. La respuesta correcta es sostener las dos a la vez, y decidir con cuál se entra.
Por qué el organigrama pierde la portada
La estructura administrativa tiene un defecto fatal como puerta de entrada: exige que el ciudadano ya sepa la respuesta para poder preguntar.
Para navegar por dependencias tienes que saber qué dependencia hace lo tuyo. Si lo sabes, no necesitabas el índice. Si no lo sabes —que es el caso normal— el menú por organismos te deja exactamente igual de perdido, solo que ahora con más pestañas.
Hay un segundo problema, más silencioso: el organigrama cambia. Cada administración reorganiza secretarías, funde direcciones, renombra coordinaciones. Si tu navegación principal es el organigrama, tu sitio se rompe con cada cambio de gobierno. Las categorías temáticas, en cambio, envejecen bien: “Agua” seguirá llamándose Agua dentro de tres administraciones.
Por eso la estructura administrativa no desaparece — se conserva como metadato de cada ficha, no como esqueleto de la navegación.
Construir la taxonomía temática
Aquí es donde se decide si el índice funciona. Algunas cosas que resultaron importar:
Las categorías se sacan de las necesidades, no de los nombres de los trámites. “Solicitud de contrato”, “Toma muerta”, “Constancia de no adeudo” y “Permiso de descarga” no comparten ni una palabra, pero las cuatro son Agua. Si agrupas por parecido textual, no agrupas nada.
Un trámite puede estar en más de una categoría. Esta es la decisión que más discusión genera y la que hay que ganar: la taxonomía debe ser multivalor, no un árbol. Un apoyo alimentario para menores es Alimentación y Niños y Niñas y Familia. Forzar un único padre significa que dos de cada tres personas buscan donde no está.
El número de categorías es un compromiso incómodo. Hoy son veinte. Con menos, cada una devuelve tantos resultados que vuelve a ser una lista larga. Con muchas más, elegir entre ellas cuesta más que buscar. No hay número correcto; hay que mirar cuántos trámites cae en cada una y partir o fundir las que queden ridículas.
Y necesitas un “Todos”. Suena trivial, pero es la salida de emergencia: cuando alguien no se identifica con ninguna categoría, la única alternativa a irse es ver la lista completa. Quitarlo por limpieza visual es de las cosas que más daño hacen.
Trámite y servicio no son lo mismo
Una distinción que parece administrativa y resultó ser útil para el ciudadano:
- Un trámite es algo que solicitas y que termina en un documento o una autorización: una licencia, una constancia, un dictamen.
- Un servicio es algo que el municipio te presta: clases deportivas, comedor, asesoría jurídica, atención médica.
La diferencia real, para quien busca, es qué tiene que llevar y qué va a salir de ahí. A un trámite vas con papeles y sales con un papel. A un servicio vas y te atienden. Son dos expectativas distintas, y mezclarlas en una sola lista hace que ambas se sientan confusas.
Por eso conviven como filtro de primer nivel, encima de las categorías temáticas.
Los iconos no son decoración: son parte de la búsqueda
Esta es la decisión que más subestimé al principio y de la que más convencido acabé.
Una lista de veinte categorías en texto plano hay que leerla. Palabra por palabra, de arriba abajo, hasta encontrar la que encaja. Esa misma lista con un icono por categoría se escanea: el ojo salta directo a la zona correcta sin llegar a leer.
Es una diferencia pequeña para quien navega con soltura y enorme para quien no. En un portal municipal entra gente mayor, gente con prisa y gente que no usa una web a diario. Para todos ellos, poder localizar lo que buscan solo con mirar la pantalla es la diferencia entre resolver el trámite y llamar por teléfono.
Dos cosas que aprendí poniéndolos:
- El icono tiene que ser del concepto, no del trámite. Una gota para Agua, una casa para Vivienda. En cuanto intentas ilustrar “Constancia de no adeudo” te sale un dibujo que no significa nada.
- El icono acompaña al texto, nunca lo sustituye. Un icono sin etiqueta es un acertijo, y además deja fuera a quien usa lector de pantalla. La etiqueta manda; el icono acelera.
Por qué el buscador importa más que el menú
Si tuviera que quedarme con una sola conclusión, es esta.
Las categorías sirven para explorar: cuando no sabes bien qué necesitas y quieres ver qué hay. Pero una parte grande de la gente llega con una palabra concreta en la cabeza —“predial”, “acta”, “licencia”, “beca”— y para esa persona cualquier menú es un obstáculo.
Un buscador decente sobre un catálogo de este tamaño no es un problema técnico difícil. Lo difícil es sobre qué busca:
- El nombre del trámite, obviamente.
- El nombre de la dependencia, para quien sí sabe a dónde va.
- La clave (
SGM-CRME-006y similares), porque cuando alguien te la dio en ventanilla es el término más preciso que existe. - Y, si puedes, sinónimos ciudadanos: la gente escribe “predial”, no “impuesto sobre traslación de dominio”. Ese diccionario de equivalencias es trabajo manual y es probablemente la mejora con mejor relación esfuerzo/impacto de todo el proyecto.
Un detalle nada menor: la búsqueda tiene que ignorar acentos y mayúsculas. El catálogo viene en mayúsculas y sin acentuar de forma consistente; quien busca escribe en minúsculas y a veces acentúa. Normalizar ambos lados antes de comparar evita una cantidad enorme de “sin resultados” injustos.
El catálogo no lo escribes tú
Esta es la parte que no aparece en ningún tutorial de arquitectura de información y que define el proyecto entero.
Los datos los redactan las dependencias. Cada dirección manda sus trámites con su nombre, sus requisitos y su clave. Tú no controlas la ortografía, ni el criterio para nombrar, ni el nivel de detalle. Llegan nombres larguísimos, abreviaturas distintas para lo mismo y mayúsculas sostenidas.
De ahí salen dos consecuencias de diseño:
- La interfaz tiene que aguantar datos feos. Un título de doce palabras en mayúsculas no puede romper la tarjeta. Se diseña para el peor caso real, no para el ejemplo bonito del mockup.
- La clave es el único identificador de confianza. Los nombres cambian entre versiones del catálogo; la clave no. Es lo que te permite actualizar sin duplicar y enlazar una ficha sabiendo que el enlace va a seguir apuntando a lo mismo.
Y una recomendación que daría a cualquiera que empiece algo así: guarda la categoría temática en tu lado, no en el de ellos. Es tu capa de valor y es lo que más vas a ajustar. Si la mezclas con los datos que llegan de las dependencias, cada actualización del catálogo te la pisa.
Qué haría distinto
- Empezar por los veinte trámites más buscados, no por el catálogo completo. La taxonomía sale mucho mejor si la construyes desde la demanda real y luego encajas el resto, en vez de intentar clasificar el catálogo entero de golpe.
- Instrumentar el buscador desde el primer día. Las búsquedas sin resultados son la mejor lista de tareas que vas a tener: cada una es alguien que no encontró algo que probablemente sí existe, y te dice literalmente con qué palabra lo buscó.
- Tratar el diccionario de sinónimos como parte del producto, no como un extra. Es donde vive casi toda la distancia entre el lenguaje del ayuntamiento y el de la gente.
Para llevarte
- Lo que vas a recibir es un Excel con enlaces a PDF. Publicarlo tal cual cumple el expediente y no resuelve nada: el trabajo es convertirlo en algo navegable.
- Un ayuntamiento te va a entregar sus trámites ordenados por organigrama. Ese orden es real, pero es metadato, no navegación.
- La taxonomía temática hay que construirla, tiene que ser multivalor, y necesita un “Todos”.
- Los iconos por categoría no son adorno: convierten una lista que hay que leer en una pantalla que se escanea.
- Trámite y servicio son expectativas distintas: sepáralos.
- El buscador es la puerta principal para quien ya sabe qué quiere. Que busque también por dependencia y por clave, y que normalice acentos.
- No controlas la calidad de los datos de origen: diseña para el peor caso y ancla todo a un identificador estable.
