Jamly • App mobile
Diseño de app para conectar músicos emergentes con venues
Role
UX/UI Designer
Timeline
MVP conceptual · 10 semanas · 2024
Team
1 Designer
Skills
UX Research
User flows
Prototipado
Design System
100%
completó las 3 tareas clave sin ayuda (Maze, 5 usuarios, wireframes)
0%
misclicks en las 3 tareas
< 17 s
promedio por tarea, desde encontrar un evento hasta postularse
Contexto
Los músicos emergentes dependen de canales informales para conseguir fechas. Jamly centraliza ese proceso.
En Argentina, conseguir una fecha para tocar en vivo requiere tener contactos, mandar mensajes por WhatsApp, esperar respuestas que no llegan y negociar condiciones que nadie pone por escrito. Jamly conecta músicos emergentes con venues, unificando descubrimiento, postulación y gestión de bookings en un solo lugar.
El diseño partió de una pregunta concreta: ¿por qué un proceso tan frecuente en la escena musical independiente sigue siendo tan informal? La respuesta no era tecnológica, era de confianza e información. El diseño resolvió ambas.
8
músicos independientes entrevistados
20
participantes en el card sorting abierto
4
referentes analizados en el benchmark
3
flujos validados con Maze
El problema
Un proceso frecuente, fragmentado en canales que no fueron diseñados para esto.
Conseguir una fecha para tocar no es algo excepcional, es algo que los músicos emergentes hacen constantemente. Pero el proceso ocurre en WhatsApp, Instagram DMs, emails que nadie responde y llamadas telefónicas. No hay visibilidad, no hay transparencia en las condiciones y no hay forma de construir reputación fuera del círculo inmediato.
Objetivos de diseño
Centralizar el descubrimiento
Fechas y artistas en una sola plataforma, sin depender de canales dispersos.
Transparencia en las condiciones
Pago y equipamiento visibles antes de postularse, no después de comprometerse.
Visibilidad fuera del círculo de contactos
Que un músico emergente pueda llegar a venues nuevos sin depender de conocidos.
Confianza verificable
Un sistema de reputación entre músicos y venues, no referencias informales.
Research
Entrevistas, benchmark y síntesis: 6 insights que derivaron en decisiones concretas.
El research combinó dos fuentes: benchmark de 4 plataformas del segmento (StarNow, mélo, BandaInvitada y gigmit) y entrevistas con 8 músicos independientes. El objetivo fue entender cómo consiguen fechas actualmente, qué los frena y qué valorarían de una solución digital.
Benchmark (4 referentes del segmento)
Los cuatro referentes priorizan la visibilidad del artista pero presentan limitaciones en transparencia de condiciones y herramientas de gestión. gigmit es el que más se acerca al modelo de Jamly (rider técnico y contrato dentro de la app), pero ninguno resuelve la comunicación centralizada entre músico y venue dentro de la misma plataforma.
Entrevistas (5 patrones con conteo directo)
Distinta frecuencia de shows entre los entrevistados, pero los mismos patrones de fricción se repiten en todos.
6 insights (4 con voz directa de las entrevistas)
Cada insight derivó en una decisión de diseño concreta. Los otros dos (dependencia de contactos personales y necesidad de verificar la difusión del venue) completan la lista de 6 y quedan documentados en El problema y en el perfil de venue respectivamente.
Usuarios
Marketplace de dos lados, pero no simétrico: el músico concentra la mayor complejidad.
Jamly es un marketplace de dos lados: músicos que buscan fechas y venues que buscan artistas. El diseño priorizó al músico emergente como usuario principal, sus necesidades son más complejas y representan el mayor desafío de retención de la plataforma. El diseño del lado venue queda documentado como próximo paso.
Perfil priorizado (Fernando, 27 años · músico indie · Buenos Aires)
Toca una vez al mes. Consigue fechas por contactos pero quiere llegar a venues nuevos.
Persona compuesta que sintetiza patrones comunes a los 8 músicos entrevistados, no un caso puntual. Su fricción central no es la falta de lugares: es la asimetría de poder, los venues ponen las condiciones y él las acepta o pierde la fecha.
Mapa de empatía (qué piensa y siente, qué dice y hace Fernando)
Dos cuadrantes: estados emocionales y creencias internas (piensa y siente), comportamientos observados y frases recurrentes (dice y hace). Frustraciones y motivaciones ya están en la persona de arriba, acá va lo que esa tarjeta no muestra.
Jobs to be done (3 escenarios que definen el MVP)
Tres JTBDs que cubren el flujo principal del músico. Cada uno derivó en decisiones de diseño concretas.
Arquitectura
Card sorting con 20 participantes para que los usuarios definieran la estructura del producto.
En lugar de definir la arquitectura desde una perspectiva interna, se hizo un card sorting abierto para identificar patrones naturales de agrupación. Los niveles de consenso oscilaron entre 44% y 89%, mostrando una estructura consistente en las categorías principales que luego definieron la navegación del MVP.
Dendrograma (resultados del card sorting)
El análisis mediante similarity matrix y dendrograma identificó tres categorías con el mayor consenso entre participantes: Perfil, Eventos y Búsqueda. Estas tres categorías se convirtieron en las secciones principales de navegación del MVP.
Decisiones de arquitectura (qué se tomó del card sorting y qué se ajustó)
El card sorting definió la estructura de primer nivel. Cuatro ajustes posteriores resolvieron tensiones entre lo que los usuarios agruparon instintivamente y lo que el flujo del producto requería, con distinto nivel de respaldo en los datos cada uno.
Mapa de arquitectura de la información
La arquitectura final organiza el producto en cinco secciones principales con máximo 2 niveles de profundidad. Cada sección responde a un estado distinto del músico: descubriendo o buscando, gestionando postulaciones y guardados, o mostrando su perfil artístico.
Flujo principal (Explorar → Filtrar → Evaluar → Postularse → Seguimiento)
El flujo principal del músico cubre el recorrido desde el descubrimiento de una fecha hasta el seguimiento de la postulación. Cada paso resuelve un insight del research: los filtros resuelven el problema de ruido, la ficha de evento resuelve la falta de transparencia, los estados resuelven la incertidumbre post-postulación.
Flujo operativo (decisiones y validaciones del sistema)
El flujo operativo documentó las decisiones del sistema, las validaciones de datos y los estados alternativos involucrados en el proceso de postulación. Complementa el flujo del usuario con la lógica interna del producto.
Wireframes
El proceso de pensamiento: exploraciones, alternativas descartadas y solución elegida.
Los wireframes se desarrollaron en dos rondas. La primera exploró dos direcciones para las pantallas críticas. La segunda consolidó la solución final a partir de los criterios de descarte de la primera ronda. La pantalla más iterada fue la ficha de evento, el punto donde el músico decide si postularse o no.
Alternativas evaluadas y descartadas
Para las pantallas críticas del flujo se evaluaron al menos dos direcciones antes de consolidar la solución. En Home/Explorar, las dos direcciones resultaron ser pantallas distintas y no una elección entre ambas.
Wireframes finales
Wireframes de media fidelidad para las 6 pantallas del flujo principal: Home, Búsqueda, Filtros, Resultados filtrados, Detalle del evento y Confirmación.
Validación
Validación temprana con los wireframes finales (5 usuarios, 3 flujos validados).
Antes de invertir en el diseño visual, el flujo de postulación se testeó mediante Maze, sobre un prototipo armado con los wireframes finales, para validar la lógica antes de pulir la interfaz. Las tres tareas se completaron con éxito, sin errores de navegación.
5
Usuarios testeados con Maze
100%
Task success rate (las 3 tareas)
0%
Misclick rate en las 3 tareas
Tareas evaluadas y resultados
Las mismas tres tareas clave del producto, evaluadas sobre los wireframes.
Encontrá un evento en Buenos Aires para el próximo mes.
Criterio de éxito
Llega al evento sin ayuda externa, usando filtros o búsqueda directa.
Resultado
5 de 5 completaron la tarea, en un promedio de 16.4 segundos.
Estado
ValidadoRevisá las condiciones de pago y el equipo técnico de un evento antes de postularte.
Criterio de éxito
Encuentra la sección de condiciones (pago y equipo técnico) sin ayuda.
Resultado
5 de 5 completaron la tarea, en un promedio de 7.5 segundos.
Estado
ValidadoPostulate a un evento eligiendo un horario disponible y confirmá tu postulación.
Criterio de éxito
Completa la postulación sin abandonar el flujo.
Resultado
5 de 5 completaron la tarea, en un promedio de 15.3 segundos.
Estado
ValidadoEncontrá un evento en Buenos Aires para el próximo mes utilizando los filtros de búsqueda.
Criterio de éxito
Usa el filtro de tipo de evento o ubicación en vez de buscar manualmente, validando las categorías definidas en las decisiones de diseño.
Resultado
Pendiente de testeo
Estado
PendienteDiseño Visual
Sistema de diseño, pantallas finales y prototipo interactivo.
El diseño visual se construyó sobre tres principios derivados del research: claridad de información antes del compromiso, visibilidad de estado en todo momento y confianza construida desde el perfil artístico. El Design System garantizó consistencia en las 8 pantallas del prototipo.
Design System
Resumen visual del Design System.
Pantallas finales (flujo principal)
Ocho pantallas del prototipo final que recorren el flujo completo: descubrir en Home, filtrar y explorar, evaluar las condiciones técnicas del evento, postularse eligiendo horario, confirmar el envío, hacer seguimiento del estado de la postulación y resolver dudas por mensajería contextual.
Home
Filtros
Explorar
Detalle del evento
Postulación
Confirmación
Mis postulaciones
Mensajería
Impacto
Qué resuelve el MVP y qué queda para la siguiente iteración.
El MVP resuelve acceso e información para músicos emergentes, no el booking completo, que requeriría el lado venue, calendarios y pagos. Scope explícito para no prometer de más.
Músicos sin acceso a venues fuera de su red de contactos
ResueltoExplorador de fechas con filtros por ciudad, género y tipo de venue, accesible para cualquier músico registrado
Condiciones técnicas y de pago opacas hasta el último momento
ResueltoFicha de evento con condiciones técnicas en un tab propio (Condiciones), evitando un scroll largo antes del CTA de postulación
Incertidumbre post-postulación (¿lo leyeron? ¿me van a llamar?)
ResueltoSistema de estados de postulación con notificaciones de cambio
Venues sin forma de evaluar artistas nuevos de forma confiable
ParcialPerfil del artista con material audiovisual y reviews, el sistema de reputación necesita masa crítica de usuarios para funcionar bien
Gestión de agenda y pagos para el venue
Fuera del MVPEl flujo completo del lado venue (gestión de agenda, revisión de postulaciones y pagos) queda documentado como próxima iteración
Aprendizajes
Diseñar para dos lados de un marketplace desde el primer sprint es una trampa.
Diseñar para músicos y venues en simultáneo diluyó ambos lados. Enfocar el MVP en el músico emergente y dejar venue para la siguiente iteración desbloqueó el diseño, la decisión llegó tarde.
El card sorting reveló la estructura, pero no el flujo.
El card sorting definió la navegación, pero no el flujo de postulación, el corazón del producto. Eso requirió mapear el proceso paso a paso; un service blueprint previo habría ahorrado tiempo.
Qué haría diferente hoy
Entrevistar dueños de venues desde la primera semana, no solo músicos, su perspectiva cambió decisiones de arquitectura ya tomadas.
Profundizar el sistema de reputación desde el MVP, quedó como el componente menos desarrollado y necesita masa crítica de usuarios.
Próximos pasos si el proyecto continuara
Diseñar el flujo completo del lado venue: gestión de agenda, revisión de postulaciones, comunicación con artistas y publicación de fechas.
Definir el modelo de negocio e integrarlo al diseño (freemium, comisión o suscripción), cada uno cambia la jerarquía de información.
Iterar sobre el sistema de reputación: qué mostrar antes de tener masa crítica de reviews, cómo verificar shows completados y cómo gestionar abuso del sistema.