Cuando un cliente pide una web autogestionable, la idea parece sencilla: quiere poder modificar el contenido de su sitio sin depender de un desarrollador.
El problema aparece cuando interpretamos autogestionable como todo tiene que ser editable.
Más opciones, más plugins, más widgets, más campos, más libertad.
En teoría, estamos dando autonomía al cliente. En la práctica, podemos terminar entregándole un sistema más difícil de utilizar, más difícil de mantener y con muchas más posibilidades de romper la estructura, el diseño o incluso el SEO del sitio.
Después de años desarrollando proyectos de diseño web en Uruguay, llegué a una conclusión bastante simple: cuanto más complejo es un sitio, más importante es simplificar la experiencia de quien va a administrarlo.
Autogestionable no significa que todo tenga que ser editable
Una de las primeras preguntas que intento resolver en un proyecto es:
¿Qué necesita modificar realmente el cliente?
No qué podría modificar.
Qué necesita modificar como parte de su trabajo habitual.
Por ejemplo, una inmobiliaria puede necesitar cargar propiedades, modificar precios, marcar inmuebles como destacados y gestionar agentes.
Una asociación puede necesitar administrar socios, actividades, documentos o contenidos restringidos.
Una empresa de servicios quizá solamente necesite modificar servicios, proyectos realizados, integrantes del equipo y algunas llamadas a la acción.
Son necesidades completamente diferentes.
Darles a todos acceso indiscriminado al constructor visual no necesariamente los hace más autónomos.
A veces ocurre exactamente lo contrario.
Separar contenido, estructura y diseño
Una de las decisiones que más cambia la experiencia de administración en WordPress es separar estas tres cosas.
El cliente debería poder pensar:
“Voy a agregar una propiedad.”
No:
“Voy a duplicar esta página, cambiar estos widgets, reemplazar esta imagen, modificar este título y tratar de no romper nada.”
Para eso WordPress ofrece una base excelente, que podemos complementar con custom post types, campos personalizados, taxonomías, relaciones y templates.
El usuario carga datos.
El sistema decide cómo mostrarlos.
Una propiedad, un curso, un proyecto, un profesional o una actividad dejan de ser simplemente páginas y pasan a ser entidades con una estructura definida.
Esto también permite que una misma información pueda aparecer automáticamente en diferentes lugares del sitio sin tener que cargarla varias veces.
Diseñar primero el sistema, después la interfaz
Cuando un proyecto tiene cierta complejidad, intento no empezar preguntando cómo debería verse cada página.
Primero necesito entender:
- qué información existe;
- qué relaciones tiene;
- quién debe administrarla;
- con qué frecuencia cambia;
- dónde debe mostrarse;
- qué acciones necesita realizar el usuario.
Recién entonces tiene sentido diseñar la interfaz.
Este cambio de orden parece pequeño, pero evita muchos problemas posteriores.
Porque una web puede verse muy bien y, sin embargo, tener una arquitectura interna terrible.
La libertad también tiene un costo
Los page builders modernos permiten hacer prácticamente cualquier cosa.
Eso es fantástico para quienes desarrollamos sitios web.
No necesariamente para quien tiene que administrar uno.
Si cada título puede cambiar de tamaño, cada columna puede moverse, cada margen puede modificarse y cualquier bloque puede eliminarse, estamos trasladando decisiones de diseño al cliente.
Y probablemente el cliente no quiera convertirse en diseñador web.
Quiere cambiar un precio.
Publicar un proyecto.
Agregar un integrante.
Modificar un servicio.
Subir una propiedad.
La interfaz debería facilitar esas tareas y proteger todo lo demás.
Autogestión y rendimiento no deberían ser enemigos
Otro problema frecuente es resolver cada necesidad instalando un nuevo plugin.
Necesitamos una función: plugin.
Aparece otra necesidad: otro plugin.
Queremos solucionar algo pequeño: tercer plugin.
Y poco a poco el sitio acumula dependencias.
No creo que la respuesta sea simplemente “usar pocos plugins”. Hay plugins excelentes que resuelven problemas complejos muchísimo mejor de lo que tendría sentido desarrollar desde cero.
La pregunta más útil es otra:
¿Esta herramienta aporta suficiente valor como para justificar la dependencia que estamos incorporando?
Cada componente debería tener una función clara dentro de la arquitectura.
La autogestión también puede afectar al SEO
Hay otro aspecto que a veces queda fuera de esta conversación.
Cuando damos libertad para administrar contenidos, también estamos dando capacidad para modificar elementos que pueden afectar al posicionamiento:
- títulos;
- jerarquía de headings;
- URLs;
- imágenes;
- enlaces internos;
- categorías;
- contenido;
- metadatos.
Por eso una buena arquitectura debería intentar que hacer lo correcto sea fácil y hacer lo incorrecto sea difícil.
Si un tipo de contenido siempre necesita determinada estructura, podemos incorporarla al template.
Si las imágenes necesitan determinadas proporciones, podemos orientar o limitar su carga.
Si ciertos campos son fundamentales, podemos hacerlos explícitos en lugar de esperar que el usuario recuerde dónde colocarlos.
La estructura protege al sitio incluso cuando quien lo administra no sabe SEO.
WordPress no tiene por qué parecer WordPress
Esta es probablemente una de las cosas que más me gustan de trabajar con WordPress.
El panel de administración no tiene por qué conservar la lógica genérica con la que viene instalado.
Podemos adaptar la experiencia al proyecto.
En lugar de:
Entradas → Añadir nueva
el usuario puede encontrarse con:
Propiedades → Agregar propiedad
o:
Cursos → Crear curso
o:
Proyectos → Agregar proyecto
La diferencia técnica puede parecer pequeña.
Para la persona que utiliza el sistema todos los días, no lo es.
El software empieza a hablar el lenguaje de su negocio.
Cuanto más complejo es el sitio, más simple debería sentirse
Esta idea puede parecer contradictoria.
Una web con membresías, relaciones entre contenidos, automatizaciones, permisos, ecommerce o integraciones externas puede tener una arquitectura interna considerablemente compleja.
Pero el usuario no debería tener que experimentar esa complejidad.
De hecho, creo que uno de los mejores indicadores de una arquitectura bien resuelta es precisamente ese:
el sistema puede ser complejo por dentro y sencillo por fuera.
No se trata de eliminar la complejidad.
Se trata de decidir quién tiene que cargar con ella.
Y, siempre que sea posible, debería hacerlo el sistema, no el usuario.
La mejor web autogestionable no es la que permite modificar todo
Es la que permite modificar fácilmente todo lo que necesita ser modificado.
Esa diferencia cambia bastante la forma de diseñar un proyecto WordPress.
En lugar de entregar simplemente páginas editables, podemos construir sistemas en los que contenido, diseño y funcionamiento tengan responsabilidades diferentes.
El resultado suele ser una web más fácil de administrar, más difícil de romper y preparada para crecer sin convertir cada cambio futuro en un problema.
Y quizá esa sea una definición más útil de autogestionable:
no darle al usuario todas las herramientas posibles, sino darle exactamente las que necesita.
Top comments (0)