Wedify Product Design / UX/UI
Rediseñar una plataforma compleja para hacerla comprensible y escalable
Wedify —antes Plan de Bodas— es una plataforma para centralizar la gestión de bodas y otros eventos entre espacios, equipos y clientes.
La versión anterior reunía muchas funciones, pero su arquitectura y navegación hacían difícil entender qué debía hacer cada perfil y dónde encontrarlo. Parte de la configuración, especialmente la carga de servicios de cada finca, terminaba dependiendo del propio equipo de la plataforma.
El proyecto consistió en replantear la experiencia completa: reorganizar la arquitectura, adaptar la interfaz a distintos niveles de responsabilidad y convertir procesos complejos en flujos más claros y reutilizables.
- Arquitectura
- Roles
- Servicios
- Autoservicio
- Rol
- Product Designer UX/UI principal
- Tipo
- Proyecto freelance remunerado
- Periodo
- Oct 2024 – Abr 2025
- Plataformas
- Web + Mobile
01 El punto de partida
Una plataforma con muchas funciones, pero difícil de entender
Plan de Bodas ya permitía gestionar gran parte de una boda: eventos, sedes, espacios, servicios, tareas, asistentes o mesas. El problema no era la falta de funcionalidades, sino cómo estaban organizadas.
Secciones que pertenecían a contextos diferentes convivían al mismo nivel dentro de la navegación principal. Al entrar en un evento, módulos, acciones e iconos competían por atención y obligaban a conocer previamente la lógica interna del sistema para saber dónde actuar.
La complejidad también se repetía dentro de los formularios. Crear o editar información implicaba enfrentarse a pantallas densas, con poca priorización y muchas decisiones visibles al mismo tiempo.
Con pocos clientes utilizando la plataforma, parte de la operativa seguía dependiendo además del anterior propietario, que cargaba manualmente los servicios de cada finca para que después pudieran utilizarse en sus eventos.
El rediseño no podía limitarse a hacer la interfaz más limpia: había que reorganizar cómo se entendía el producto.
El reto no era reducir el número de cosas que Wedify debía permitir hacer, sino encontrar una estructura que hiciera esa complejidad manejable.
02 Reorganizar la complejidad
Pasar de un menú plano a una arquitectura contextual
El punto de partida fue un documento funcional trabajado previamente por los socios y el equipo técnico. Allí aparecían las principales entidades, datos, relaciones y necesidades del producto, pero todavía había que transformar esa lógica en una experiencia que se pudiera navegar y comprender.
Al trasladar esos requisitos a pantallas fueron apareciendo nuevas preguntas: qué debía ser global, qué pertenecía a una Masía, qué vivía dentro de un Evento y qué información necesitaba realmente cada perfil en cada momento.
También refinamos nomenclaturas que inicialmente resultaban poco comprensibles y revisamos referencias del sector —especialmente Bodas.net— para entender patrones conocidos, sin replicar su estructura. Wedify necesitaba resolver una gestión multi-sede y una jerarquía de usuarios diferente.
El cambio principal fue separar la navegación global de la navegación contextual.
Así, el menú principal podía mantenerse reducido mientras las funciones específicas aparecían dentro de la entidad a la que realmente pertenecían.
La complejidad seguía existiendo, pero ya no se presentaba toda a la vez.
La navegación dejó de intentar explicar todo el producto a la vez y empezó a acompañar al usuario según el contexto en el que estaba trabajando.
03 Diseñar según la responsabilidad
La misma plataforma no debía mostrar lo mismo a todo el mundo
Wedify debía funcionar para perfiles con responsabilidades muy distintas y con niveles de experiencia digital también diferentes.
Un Super Admin podía necesitar acceder a varias organizaciones, masías y eventos. Otros perfiles debían trabajar únicamente con las masías o eventos que tenían asignados. Los novios, en cambio, no necesitaban comprender la estructura interna del negocio: necesitaban organizar su propio evento.
Por eso la solución no consistió únicamente en ocultar botones según permisos. El acceso, la profundidad de navegación y la información de entrada se adaptaron al ámbito real de cada persona.
La interfaz se apoyó además en jerarquías claras, iconografía reconocible, estados visibles y ayudas contextuales para reducir la necesidad de aprender el sistema antes de poder utilizarlo.
Acceder solo al contexto que corresponde
Cambiar también la información de entrada
La misma lógica se trasladó a los dashboards.
El objetivo era que cada perfil comenzara por la información más útil para su trabajo, evitando obligar a todos los usuarios a pasar por una misma vista genérica.
Visión global , Gestión operativa , Organización del propio evento
Diseñar por responsabilidad permitió reducir ruido sin crear productos distintos para cada perfil: la base era la misma, pero el contexto cambiaba.
04 Servicios y Packs
Convertir la parte más compleja del producto en un sistema progresivo
Los servicios eran uno de los flujos más complejos de la plataforma anterior.
Configurar la oferta de una finca podía implicar precios, costes, valores por persona, IVA, categorías, opciones, preguntas para el cliente y relaciones entre distintos elementos. La dificultad era suficiente para que, en la práctica, el propietario de Plan de Bodas terminara cargando gran parte de esa información para sus clientes.
En el rediseño no intentamos eliminar esa complejidad. La organizamos en una estructura progresiva y reutilizable.
Empezar por piezas reutilizables
Servicio sencillo
El primer nivel es el servicio sencillo: una pieza independiente que puede reutilizarse después dentro de estructuras mayores.
Desde una misma interfaz se podían definir datos como nombre, categoría, imagen, precio, coste, valores por persona, IVA y descripción.
Una vez guardado, el servicio quedaba disponible dentro del catálogo de la Masía, desde donde podía consultarse, editarse y reutilizarse posteriormente.
Componer sin volver a introducir la misma información
Servicio agrupado
Los servicios agrupados se construían a partir de servicios sencillos que ya estaban registrados en el sistema.
Esta dependencia era importante: primero se creaban las piezas base y después podían combinarse sin volver a introducir la misma información.
Además de seleccionar qué servicios formaban parte de la agrupación, el profesional podía definir reglas de interacción con el cliente. Los valores mínimo y máximo determinaban cuántas opciones se podían elegir y la configuración del servicio condicionaba el tipo de pregunta asociada: Sí/No, selección única o selección múltiple dentro de un rango.
La complejidad se mantenía en el sistema, pero quedaba convertida en decisiones explícitas dentro del flujo.
Escalar hasta una oferta completa
Pack
Una vez creados los servicios sencillos y agrupados, la Masía podía construir Packs con una oferta más completa.
Un Pack podía combinar elementos de distintas categorías —por ejemplo restauración, decoración, fotografía o entretenimiento— y reunirlos dentro de una única propuesta.
Además de los servicios incluidos, la configuración contemplaba información comercial como precio, coste, valores por persona, IVA y el nivel de interacción previsto con el cliente.
De este modo, la oferta podía construirse por capas y reutilizar trabajo ya configurado en lugar de empezar desde cero para cada evento.
La solución no consistía en simplificar artificialmente la oferta, sino en construirla por capas: crear una vez, reutilizar y combinar.
05 Invitaciones autoservicio
Integrar una tarea que antes vivía fuera de la plataforma
Las invitaciones de boda no formaban parte de la antigua plataforma.
El propietario de Plan de Bodas las ofrecía como un servicio adicional y era él quien se encargaba de montarlas para los clientes.
En Wedify integramos ese proceso dentro del propio evento para que los novios pudieran elegir una base, personalizarla y gestionar el resultado desde el mismo producto.
Diseñamos tres plantillas con estilos diferentes. Desde la ficha del evento, la pareja podía seleccionar una y completar contenidos como nombres, fechas, localizaciones, traslados, celebración, vestimenta, fotografías y confirmación de asistencia.
El resultado final también debía poder consultarse desde Mobile, algo especialmente importante para una invitación que los invitados recibirían y abrirían habitualmente desde el teléfono.
Una tarea que antes dependía del proveedor pasó a formar parte de la experiencia del propio cliente.
Integrar las invitaciones dentro de Wedify ampliaba el autoservicio de los novios y mantenía otra parte de la organización del evento dentro del mismo entorno.
06 Resultado + implementación
Una base más clara para seguir construyendo el producto
El rediseño transformó una plataforma difícil de aprender en un sistema organizado alrededor de contextos, responsabilidades y piezas reutilizables.
La nueva arquitectura permitió separar la gestión global de la operativa de cada Masía y de cada Evento. Los accesos y dashboards se adaptaron a distintos niveles de responsabilidad, mientras que flujos complejos como Servicios y Packs se estructuraron de forma progresiva.
El trabajo cubrió tanto Web como Mobile y también incorporó experiencias orientadas al cliente, como la edición de invitaciones dentro del propio evento.
01 Arquitectura contextual
Las funciones aparecen dentro de la entidad a la que pertenecen, en lugar de competir todas dentro de una navegación global.
02 Experiencia según responsabilidad
El producto cambia la profundidad de acceso y la información de entrada según el ámbito de cada perfil.
03 Configuración reutilizable
Servicios sencillos, servicios agrupados y Packs permiten construir ofertas complejas a partir de piezas previamente configuradas.
04 Más autoservicio
Funciones como las invitaciones pasan a estar integradas dentro de la experiencia de los propios clientes.
Diseño e implementación en paralelo
Para facilitar la implementación trabajamos sobre Material Design y personalicé un tema de Flutter para adaptar el lenguaje visual de Wedify.
No construí un Design System independiente desde cero. La base era Material Design: configuré el tema, personalicé componentes cuando era necesario y revisamos varias veces cómo esa configuración se traducía en la interfaz real.
Algunas decisiones no podían resolverse únicamente desde el tema y necesitaron ajustes específicos por parte de desarrollo. Esa colaboración formó parte del trabajo cotidiano entre diseño y código.
Trabajé como Product Designer principal, con apoyo puntual de otra diseñadora para agilizar parte de la producción visual y con revisión/refinamiento final a mi cargo, en colaboración con Samuel y el equipo de desarrollo.
Antes de terminar mi participación pude ver implementadas partes del producto como el acceso, algunos dashboards y las plantillas de invitaciones. Sin embargo, salí del proyecto antes de que la plataforma completa estuviera finalizada.
Aprendizaje
Simplificar un SaaS complejo no significa eliminar funciones, sino decidir cómo se agrupan, cuándo aparecen y para quién son relevantes.
Wedify me obligó a trabajar con complejidad real: múltiples niveles de usuario, entidades relacionadas y flujos en los que una pieza podía convertirse en parte de otra mayor.
El aprendizaje principal fue entender que una interfaz puede sentirse mucho más sencilla sin reducir la capacidad del producto, siempre que la arquitectura, el contexto y la jerarquía ayuden a mostrar cada decisión en el momento adecuado.