Product Design / Consumer / Growth
De búsquedas fragmentadas a un producto de discovery para aprovechar mejor el cumpleaños
Diseñé y evolucioné una plataforma que organiza beneficios de marcas y comercios, conectando discovery, contenido estructurado, confianza y crecimiento orgánico.
Si hoy cumplís años, el regalo no lo ponés vos
Explorá todos los beneficios para tu cumple en Buenos Aires.
Un comportamiento que ya existía
Cada año se repite el mismo patrón: personas buscando listas, videos y publicaciones sobre lugares que ofrecen algo gratis o con descuento por cumpleaños. No era un comportamiento nuevo. Era uno fragmentado.
La oportunidad no nació de inventar una necesidad. Nació de estructurar una conducta que ya ocurría en redes sociales, búsquedas individuales y recomendaciones entre amigos.
Cumpleañito partió con foco en Buenos Aires, donde la concentración de marcas y la densidad de búsquedas hacían viable un primer catálogo con más de 150 beneficios recopilados.
Reunir beneficios no alcanzaba
Una lista estática no responde las preguntas que realmente importan cuando alguien decide si vale la pena ir a un local o registrarse en una app:
- ¿Sigue vigente?
- ¿Dónde aplica?
- ¿Necesito registrarme antes?
- ¿Es solo el día del cumpleaños o todo el mes?
- ¿Funciona en todas las sucursales?
- ¿Cómo lo canjeo?
- ¿A otras personas les funcionó?
El valor no estaba solamente en reunir beneficios, sino en estructurar suficiente contexto para que una persona pudiera decidir si realmente podía aprovecharlos.
Múltiples caminos hacia el mismo beneficio
No todas las personas llegan igual. Algunas saben qué rubro les interesa; otras buscan cerca de su barrio; otras quieren filtrar por condiciones antes de comprometerse. El producto necesitaba soportar todas esas intenciones sin duplicar contenido.
| Dimensión | Ejemplo | Ruta / mecanismo |
|---|---|---|
| Categoría | Gastronomía, Moda, Belleza… | /beneficios/categoria/[slug] |
| Ubicación | Palermo, Recoleta, Belgrano… | /beneficios/[barrio] |
| Búsqueda | Query en header → /beneficios?q= | /beneficios |
| Tipo | Regalo vs. descuento | Filtro en listado |
| Condiciones | Verificado, sin compra mínima | Filtros laterales |
| Orden | Relevancia, mejor calificados, recientes | Parámetro orden |
| Mapa | Exploración espacial | /mapa |
| Favoritos | Lista personal | /favoritos |
Estructurar era una decisión de producto
Cada beneficio necesitaba transformarse en una entidad con campos definidos. No era solo una decisión técnica: determinaba qué podía buscarse, filtrarse, comparar, indexarse y escalar.
El modelo incluye marca, tipo de beneficio, categoría, ubicación, sedes múltiples, instrucciones de canje, condiciones, vigencia y señales de validación comunitaria.
Prioricé campos que respondían preguntas reales de decisión, no metadata decorativa. Si un campo no ayudaba a filtrar, comparar o generar confianza, no entraba al modelo.
Cada campo habilita búsqueda, filtrado, comparación o señales de confianza
| Campo | Propósito en producto |
|---|---|
| Marca | Identificación y confianza |
| Título | Propuesta en una línea |
| Descripción corta | Evaluación rápida en listados |
| Descripción larga | Contexto en detalle |
| Tipo | Regalo, descuento, 2x1 u otro |
| Categoría | Discovery por interés |
| Ubicación | Relevancia geográfica |
| Sedes | Múltiples puntos de canje |
| Canje | Presencial, online, código o link |
| Instrucciones | Reducir incertidumbre |
| Días aplicables | Ventana de uso |
| Compra mínima | Condición económica |
| Acompañantes | Requisito social |
| Advertencia | Excepciones y matices |
| Verificado | Señal de confianza editorial |
| Votos | Validación comunitaria |
¿Qué necesita saber alguien antes de abrir un beneficio?
La card debía permitir evaluar relevancia sin abrir el detalle, incluso cuando la información disponible variaba entre marcas. Nombre, propuesta, categoría, ubicación, tipo de beneficio y señales de confianza aparecen en jerarquía visual clara.
Los filtros laterales permiten reducir ruido por barrio, categoría, tipo (regalo vs. descuento), verificado y sin compra mínima, con ordenamiento por relevancia, calificación o fecha.
Bebida gratis en el mes
Bebida gratis a elección en el mes del cumpleaños para usuarios registrados.
Réplica basada en BenefitCard, datos de Starbucks del catálogo real
De "parece interesante" a "sé cómo aprovecharlo"
La página de detalle no debía vender el beneficio. Debía reducir incertidumbre. Para eso concentra descripción larga, requisitos, días aplicables, compra mínima, acompañantes, advertencias, instrucciones de canje y ubicaciones con mapa.
El flujo de canje requiere declarar intención ("Quiero usar este beneficio") antes de revelar instrucciones completas. Esto permite medir interés real y preparar al usuario para el momento de uso.
Compartir, guardar en favoritos y votar conviven en la misma capa. Cada uno responde una necesidad distinta: difundir, posponer o validar.
No fingir certeza absoluta
Los beneficios cambian, vencen, varían por sucursal y dependen de condiciones que las marcas no siempre documentan bien. El producto no debería presentar todo como verificado al 100%.
La confianza se construye con señales editoriales (badge verificado), fechas de vigencia, votos comunitarios, reportes de usuarios y advertencias explícitas cuando la información es incompleta.
En un producto basado en información cambiante, la confianza depende tanto de lo que mostramos como de cómo comunicamos incertidumbre.
¿Te funcionó este beneficio?
Una respuesta binaria responde la pregunta principal: ¿sigue vigente?
Una base centralizada no escala sola
Implementé un sistema de votos binarios: "¿Te funcionó?" con opciones Sí / No. Un voto por usuario por beneficio. No es un sistema de reviews. Responde la incertidumbre principal: si el beneficio sigue vigente en la práctica.
Complementado con reportes que notifican al admin por email cuando alguien detecta información incorrecta o un beneficio que ya no funciona.
Una respuesta binaria puede ser más útil que un sistema de reviews completo cuando la principal incertidumbre es si el beneficio sigue funcionando, no cómo fue la experiencia gastronómica.
Discovery y uso no ocurren en la misma sesión
La mayoría de las personas no descubre un beneficio exactamente el día que lo van a usar. Pueden encontrarlo semanas antes, durante una planificación o por recomendación de un amigo.
Los favoritos permiten construir una intención futura: guardar, volver cuando se acerque el cumpleaños y tener una colección personal en /favoritos.
Asset real del producto: empty state de favoritos
Las personas ya buscaban estas respuestas
El desafío fue alinear la arquitectura del producto con comportamientos de búsqueda existentes, no agregar SEO como capa posterior. Categorías, barrios, beneficios individuales y blog generan páginas indexables con metadata, Open Graph y JSON-LD Offer schema.
Rutas confirmadas en sitemap.ts y estructura de App Router. /buscar redirige permanentemente a /beneficios; /ubicaciones redirige a /mapa.
Crecimiento orgánico como consecuencia del producto
El producto puede crecer mediante tráfico orgánico (SEO), compartir beneficios en redes, contribuciones de usuarios, registro para interacciones y retorno por favoritos. No diseñé pop-ups agresivos ni gates de contenido. El growth viene de utilidad real.
Hipótesis de producto
Crecer sin degradar calidad
En /sumar-beneficio, cualquier persona puede recomendar un beneficio sin necesidad de cuenta. El formulario pide nombre del comercio, título, descripción e instrucciones de canje: lo mínimo para evaluar la propuesta.
Las contribuciones entran como draft con is_user_submission. El admin completa categoría, imagen, ubicación y demás campos obligatorios antes de publicar desde el tab "Pendientes".
Permitir contribuciones amplía cobertura, pero introduce un nuevo problema: cómo crecer sin degradar la calidad de la información.
Preparar el contexto desde el registro
Después de crear cuenta, el onboarding recopila nombre, fecha de nacimiento, intereses (regalos, descuentos, promos con amigos) y tipos de plan (comer afuera, compras, salidas). También ofrece activar recordatorio de cumpleaños.
Hoy estas preferencias preparan personalización futura: no hay algoritmo de recomendación implementado. La decisión fue capturar intención sin prometer personalización que aún no existe.
Una marca no siempre equivale a una ubicación
Muchos beneficios aplican en múltiples sucursales con direcciones distintas. El modelo benefit_locations permite vincular un beneficio a varias sedes con coordenadas y dirección específica.
En /mapa, Google Maps muestra marcadores filtrables. En el detalle, el mapa y listado de direcciones responden: "¿a cuál voy?"
Separé location_id (barrio principal para SEO y filtros) de benefit_locations (sedes específicas para canje) para no forzar una sola ubicación cuando la realidad es más compleja.
Consistencia cuando el catálogo crece
A medida que el catálogo creció, la consistencia dejó de ser estética y pasó a ser funcional. Mismas cards en home, listados, categorías y barrios. Mismos chips de categoría. Mismos estados vacíos. Mismos patrones de favorito, voto y compartir.
Los design tokens del producto (primary #a77dea, secondary #fee177, tipografía Nunito) se mantienen en todo el flujo, desde la card hasta el modal de autenticación.
No construí un design system documentado aparte. Construí patrones que se repiten porque el producto los necesita en cada punto de contacto.
Beneficio con ventana de días ambigua
- Qué podía pasar
- Algunas marcas aplican el beneficio solo el día del cumpleaños; otras, todo el mes.
- Riesgo
- Expectativas incorrectas y frustración en el local.
- Decisión
- El campo days_applicable aparece en detalle y, cuando está disponible, en la card como fecha de vigencia.
Múltiples sedes con condiciones distintas
- Qué podía pasar
- Una marca puede tener presencia en varios barrios, pero no todas las sucursales participan.
- Riesgo
- La persona llega al local equivocado.
- Decisión
- Relación many-to-many benefit_locations con mapa interactivo y listado de direcciones en el detalle.
Requisito de app o registro previo
- Qué podía pasar
- Starbucks Rewards, apps de fidelización, membresías.
- Riesgo
- Llegar sin preparación y perder el beneficio.
- Decisión
- redemption_instructions y warning_text visibles solo después de declarar intención de uso, para no saturar la card.
Información incompleta al publicar
- Qué podía pasar
- Contribuciones de usuarios llegan sin categoría, imagen ni ubicación.
- Riesgo
- Contenido de baja calidad en el directorio.
- Decisión
- Submissions entran como draft; el admin completa campos obligatorios antes de publicar.
Beneficio posiblemente vencido
- Qué podía pasar
- Promociones cambian sin aviso en sitios de marcas.
- Riesgo
- Pérdida de confianza en la plataforma.
- Decisión
- Votos binarios, reportes de usuarios y badge de verificado editorial, sin fingir certeza absoluta.
Más beneficios vs. mejor calidad
Aumentar cobertura mejora discovery y SEO, pero incrementa el riesgo de información obsoleta o incompleta.
Decisión: Flujo de publicación con moderación admin y señales comunitarias para priorizar lo vigente.
Menos fricción vs. más contexto
Una card simple facilita exploración, pero puede ocultar condiciones que importan para decidir.
Decisión: Jerarquía en dos capas: evaluación rápida en listado, reducción de incertidumbre en detalle.
Crecimiento abierto vs. moderación
Permitir contribuciones escala contenido, pero introduce ruido y duplicados.
Decisión: Formulario público en /sumar-beneficio → estado draft → revisión en panel admin.
SEO vs. navegación
Páginas indexables por categoría y barrio capturan búsquedas long-tail, pero deben seguir siendo útiles para usuarios reales.
Decisión: Landings con el mismo componente de listado y filtros que el directorio principal, no páginas vacías de SEO.
Registro vs. acceso
Pedir cuenta permite favoritos, votos y personalización, pero introduce fricción en discovery.
Decisión: Navegación y listados abiertos; interacciones (favorito, voto, canje) requieren autenticación.
A medida que aparecieron nuevas necesidades, el producto fue incorporando capas. No hay cronología con fechas confirmadas. Esta es la secuencia lógica de evolución observada en el código y la estructura actual.
Migración desde WordPress hacia Next.js con beneficios estructurados, categorías y páginas de detalle con metadata SEO.
Filtros por ubicación, tipo, verificado y compra mínima. Landings por categoría y barrio. Mapa con Google Maps.
Votos binarios, intención de canje, reportes, badge verificado y compartir en redes.
Registro (Google + email), onboarding con preferencias, favoritos, publicación de beneficios y panel admin.
ISR, prefetch server-side, optimización de edge requests, sitemap dinámico y JSON-LD Offer schema.
Señales de tracción
Un comportamiento existente puede convertirse en producto
La oportunidad no estaba en inventar la necesidad de aprovechar el cumpleaños, sino en estructurar mejor una conducta que ya ocurría en redes, búsquedas y recomendaciones.
Más contenido no equivale a más valor
La utilidad depende de contexto, calidad y capacidad de decidir. Agregar beneficios sin estructura solo reproduce el problema original en otro formato.
La confianza necesita diseño
Cuando la información cambia, la experiencia debe mostrar señales claras, permitir feedback y comunicar incertidumbre sin debilitar la propuesta.
SEO puede revelar el modelo mental
Las búsquedas por categoría, barrio y marca mostraron cómo las personas formulan sus necesidades, y eso informó la arquitectura de información.
Consumer Product Design también es arquitectura
Una experiencia aparentemente simple (buscar, filtrar, guardar) depende de taxonomías, estados, reglas de moderación y loops de validación.
El producto evolucionó a partir del comportamiento observado, feedback de usuarios, datos de uso y nuevas necesidades detectadas durante su crecimiento, no de un proceso de research formal documentado.
Más proyectos
B2B • Marketplaces • SaaS / herramientas de gestión
Diseñando el flujo que convierte campañas y postulaciones en colaboraciones
Campaña en vivo, postulaciones entrando, creador por elegir. Diseñé el puente entre marca y creador sin perder contexto hasta colaborar.
Fintech
Diseñando claridad para cartera, posiciones, movimientos y operatoria financiera
Plataforma white label de trading y cartera para agentes de bolsa. Pantallas densas donde claridad y operatoria tenían que convivir.