Todos los proyectos
Domar miles de webs en WordPress
Aplicación web para mantener webs en WordPress, y el sistema de diseño que la sostiene.
- Product Designer
- Diseño de producto · SaaS
- 2024 - Hoy
- Dirección y dos desarrolladores
- Desde julio de 2024, bajo demanda
- Funcionalidades de producto y sistema de diseño
En resumen
En julio de 2024 me convertí en el diseñador de producto externo de una plataforma que gestiona webs en WordPress. Más de treinta funcionalidades después, todas publicadas, el producto tiene además un sistema de diseño rehecho a partir de lo que hay de verdad en producción.
- 2+
- 570+
- 30+
- 2
- 61
- 30K+
El contexto
El producto es una plataforma SaaS con la que agencias y freelances mantienen muchas webs en WordPress desde un mismo sitio: plugins, actualizaciones, copias de seguridad, monitorización de disponibilidad y de seguridad, e informes para sus propios clientes. La usan miles de ellos, en más de cien países, para cuidar de decenas de miles de webs.
Llegué en julio de 2024. El producto crecía deprisa y el equipo, muy técnico, quería sumar una mirada de diseño. Desde entonces trabajo bajo demanda, unos meses treinta horas y otros, cinco, casi siempre con la dirección de la empresa y con dos desarrolladores.
Empecé por el gestor de plugins, que diseñé desde cero aquel primer verano. A partir de ahí no he parado: la versión móvil de todo el producto, los equipos con varios usuarios, las copias de seguridad, la limpieza de la base de datos, los informes para clientes, las actualizaciones seguras y programadas, la monitorización de disponibilidad, el staging y las migraciones, un comprobador de enlaces, el análisis de malware y las pantallas para conectar el producto con asistentes de IA. Unas veces eran funcionalidades nuevas y otras, una vuelta de tuerca más a las que ya existían.
El sistema de diseño fue lo último en llegar. En septiembre de 2024 hice una primera limpieza de colores y tipografía en Figma, pero el sistema como tal no se abordó hasta el verano de 2026.
El reto
Reunir las herramientas de mantenimiento en un solo sitio era la parte fácil. La difícil era convertir lo que el backend sabía hacer en flujos que cualquiera pudiera seguir: cómo elegir webs o plugins, cómo actuar sobre muchos a la vez y qué te dice el producto en cada paso. Mucho de eso es evidente para un desarrollador y un misterio para quien solo quiere tener al día las webs de sus clientes.
El otro problema era la coherencia. Heredé un archivo enlazado a tres librerías de diseño, y producción y Figma no siempre se actualizaban a la vez, así que iba arrastrando esas diferencias de una funcionalidad a la siguiente sin darme cuenta. Además, como diseñador externo con otros proyectos en marcha, me tocaba retomar las revisiones mucho después de haber hecho la propuesta.
Mi enfoque
El trabajo, por orden:
- Briefing
- Bocetos
- Propuesta
- Anotaciones
- Revisión
Y las decisiones que le dieron forma:
Reutilizar lo que existe antes de inventar algo nuevo
Al ritmo de una startup, un patrón que ya existe se construye antes, y además el usuario ya sabe cómo se comporta. Por eso un filtro por tipo de actualización se resolvió con unas píldoras que otra pantalla ya tenía. Y en los pasos para restaurar una copia de seguridad, un componente nuevo que yo había propuesto se cambió en la revisión por un estado que ya existía, sin que el flujo perdiera nada. Un patrón nuevo tiene que ganarse el sitio. La barra de acciones en bloque del gestor de plugins se lo ganó: sin ella, actualizar o desinstalar era repetir la misma acción elemento por elemento.
Los ajustes para expertos tienen una sección propia
Las migraciones, el staging y la clonación abrieron un debate sobre cuánto lenguaje técnico enseñar. Algunos usuarios necesitan esas opciones; la mayoría solo quiere mover una web. Acordamos una sección aparte de “ajustes para expertos”, con el aviso de no tocarla si no sabes lo que haces. Así el flujo principal sigue hablando en llano.
El sistema de diseño parte de producción, no de Figma
Lo fácil era ordenar mis propios archivos de Figma y declararlos la fuente. Pero lo que ven los usuarios es producción, y eso es lo que el equipo da por bueno. Así que cada componente sale de ejemplos reales: reúno los ejemplos, los audito, decido, rehago el componente con tokens, borro el antiguo y lo documento.
En el sistema mandan los nombres del código
Dos familias de componentes se llamaban de una manera en mi archivo y de otra en desarrollo. Mantener mis nombres era menos trabajo para mí y una traducción más para todos los demás, todos los días. Los cambié: 215 tokens, 9 componentes y su documentación.
Los resultados
- Más de 30 funcionalidades y áreas de producto diseñadas, todas en producción
- Usuarios que citan el diseño como lo que más les gusta
- Acciones en bloque en el gestor de plugins
- Dos versiones mayores del producto lanzadas con mis diseños
- Un sistema de diseño de 61 componentes y 1438 variantes, rehecho desde producción en un verano
- Una colaboración que sigue en marcha
Lo que aprendí
Durante mucho tiempo me adapté a lo que ya estuviera construido. Cada vez parecía la opción rápida, pero la suma de todas esas veces era un producto con varias versiones de lo mismo. Hoy defiendo los criterios de diseño desde el principio, y dejo por escrito lo que acordamos sobre cómo se ven y cómo se comportan las cosas. Recuperar el contexto también ha resultado ser parte del trabajo: notas, transcripciones de reuniones y, últimamente, un asistente de IA que me ayuda a reconstruir una decisión tomada hace meses.
Lo que todavía no puedo decir es cuánto tiempo ahorra el sistema: nadie lo ha medido, y desarrollo no lo ha adoptado del todo. Tampoco he visto nunca a un usuario de fuera trabajando con el producto. Es lo siguiente que quiero conseguir.
Contacto
Si te he caído bien y quieres ponerte en contacto conmigo, cuéntame el proyecto, la charla o tus teorías sobre el Área 51. Escríbeme o reserva una llamada.